Has Agile Become Addiction to Instant Gratification?
sid-thinketh.medium.com
sid-thinketh.medium.com
My sister works as a project manager at one of the big UK banks. They are anything but agile--projects take months and have to be planned out to the smallest detail for legal and compliance reasons. Makes sense, as the smallest decision affects millions of people, and there are regulations to satisfy.
She complains she now has to do daily standups with other project managers. But she has no idea what they do, they have no idea what she does, and it's a matter of just talking "Yeah, doing the same thing I was doing yesterday".
But since there are like 20 managers in just her group, this takes an hour everyday.
And she's like--we're not in software, why are they forcing this scrum thing on us?
I tried to tell her about the Priesthood the Agile, the Saviours of Our Codes, bless them, the Agile Manifesto Priests, but decided it would be too much history, so I just nodded and said "meh".
It also contributes to a lot of the other examples in this convo chain. Bad agile is bad. Just like bad waterfall is bad.
A key tenant to agile is the reduction of inefficient processes. So in the next retrospective I would nominate that there are no longer weekly 20 person meetings.
It’s the standing 1 hour meeting where some people leave thinking it’s a waste of time. The waste is what agile is about, or not about. If it’s productive, needed, or even just healthy then it’s appropriate IMO.
Thx for sharing.
It is unresponsive to change. The smallest ambiguity will result in the undesirable outcome of building the wrong thing. The only good thing about Waterfall is that contractors can make bank on the rework, but their customers will be screwed every time.
For software systems, specifically, also anything that encourages early integration. Integrate early, integrate often. A failure to do so means that you've broken your feedback loops or extended them to an arbitrary time in the future so that they have little to no value. You cannot properly verify and validate a system without integrating the major subsystems.
Independent of most of the named processes and the technical discipline, V&V. Verification and validation are critical, ongoing activities that must be part of your work. This largely pushes towards automated testing, formal specs where applicable, and customer collaboration (to get validation of the system at critical junctures).
Waterfall doesn't do any of those things or isolates them (like V&V). It only works on large scale systems if reality matches expectations, which is rare.
My preference is to look towards Lean Software, most of the Agile methods, and the classical methods like Iterative & Incremental and Evolutionary (which were agile before Agile). V-Model is Waterfall-ish but integrates feedback into the system and makes V&V an ongoing activity. I prefer it paired with I&I or Evolutionary for critical systems (my primary domain).
Sometimes, but in my experience anarchy (which adds some business value, in a non specific way) is often better than waterfall (which adds none and actually hinders by preventing small quick schemes that add value now for the promise of value in years to come)
No, but like any practice that becomes known of outside a narrow group of highly-competent, highly-motivated experts in the relevant area, TDD can be (and often is) cargo culted. It is thus often the case that people's only practical contact with “TDD” is with a cargo cult application of it.
Agile places software and documentation at opposition - TDD tries to tie them together.
TDD was developed in the 1990; Agile was articulated in 2001. Were they actually opposed, “Agile is a repudiation of TDD” would be more defensible. But your basic premise is wrong...
> Agile places software and documentation at opposition
No, the “X over Y” statements in the Manifesto aren't about opposition, they are about subordination. ”over” can be substituted with “should shape the use of” rather than “should exist instead of”
As for the "X over Y" statements, well, it's a rhetorical style which definitely creates an implicit opposition. Subordination makes no sense here. Our job and the business value is in working software, of course we want that most of all. Why mention it over something unless that something is in the way and we want to discourage it?
Let's say I told people "Crossing the road over obsessively looking at both sides of the road"*, and kept referring to "obsessive looking" while barely mentioning people should look at all. As guidance this is horrible, for reasons I believe are obvious. If I said later "I only meant obsessive looking" and "you should adjust your crossing process so it suits you" it wouldn't make my advice right, would it now?
* Documentation is of course much less necessary, I'm just taking an extreme example to show the rhetorical style.
The value of the items on the right (per the manifesto, if you disagree on the relative values that part can be debated) is lower than the value of the items on the left, but it is not zero or negative.
If we were to declare doing X as contrary to getting the job done, always describe X with demeaning or excessive terms, and give no limiting principal when X is actually important, we shouldn't get shocked when people read what we wrote, and decide X is at best unimportant, because that's what we really wrote whatever we intended.
Sure, we could later write a blog saying 'we never actually told you not to do X' and be technically correct, but in reality we gave bad guidance that drove people away from X even when X was actually important.
Wikipedia gives a shorter version:
In fact Royce, known for his 1970 paper from which the Waterfall model for software development was mistakenly drawn, demonstrated that while the development of large software systems required a more thorough approach, there was inherent risk in a single-pass sequential approach. He proposed an iterative approach and advocated that projects should pass through this at least twice.
There was the line about "not introducing much process and structure," as basic Agile principles. I completely agree (and have said so, myself[0]), but the issue is that software folks (and engineers, in general), don't like "blurred lines." We need empirical data, measurable artifacts, concrete results, etc., so that "fuzzy logic," (what I consider) "true" Agile really needs, is difficult, in practice.
This is why I think that experienced engineers, that treat the vocation as a "craft," are often better suited to "true" Agile. They understand the ramifications of decisions that need to be made quickly (without having to run a formal risk analysis and methodology review).
Remember that the authors of the Manifesto were all highly experienced and capable engineers. They wrote a document that basically chronicled the way that they, themselves, approached development.
As for bugs and tech debt; personally, I abhor debt, of any kind. That posture has served me very well, in life. Tech debt is just another loan shark.
I like to run on what I call "constant beta." The application is always what I consider to be "bug free" (we all know it isn't, but let me have my happy place). If I encounter a bug, I stop all forward movement, and fix it; even if it is a "small" bug.
As you can imagine, this was not something my managers used to allow, but, as I no longer have a manager, I do it this way.
It works wonderfully.
[0] https://littlegreenviper.com/miscellany/concrete-galoshes/
Reading through the Toyota production system this is one of the things that is recommended for finding issues early before they become big issues. Stop the manufacturing line, find out what's wrong, fix it, continue.
At the beginning you will be stopping a lot, and I still am in awe of the manager that got this technique approved the first time, but after a while you will find that you just produce fewer bugs by virtue of a) recognizing patterns in how you produce bugs and avoiding them, and b) not having to work around as much technical debt, these clever workarounds are what bites you later.
It's everywhere from Lean to that insufferable Mary Sue of the Phoenix book. It makes for decent storytelling, but it has nothing to do with how any successful software has ever been made. There is no assembly line and we do not pause it. It is a parable that is actively unhelpful. Lean manufacturing was not even invented to develop or design cars, so it's purported origins doesn't even make sense.
See also "software is like construction work" which used to be popular before. That wasn't useful either, and anyone who's seen the construction business knows it's nothing like management literature of yesteryear would make it out to be.
Sorry for the rant. I don't hate agile. This just happens to be a sore spot, comparing software to "a car" is intellectually lazy. We should be able to do better. It's easy to imagine the day when someone asks why we can't design cars the same way we design software. Not the other way around.
I also disagree that the equivalent of stopping the production when you spot a defect is fixing your bugs as soon as you see them. The equivalent would be something more meta, as asking yourself why that bug was created and changing the way you work (like in adding a linter rule).
Which is exactly what you do after stopping that production line and finding the issue.
I have the luxory of no manager either, but I like to move fast and not have the cost of context switch, to immediately fix every small UI bug or glitch, like I used to.
I rather keep track of them and usually wait, till I drown in warning messages - and then I take the time to properly clean up and refactor things.
I found out, this way I am more efficient. Because since I suffer from perfectionism, I would get lost in fixing and improving small things. Now I mostly ignore them and focus on the important stuff and only fix things immediately, if they are in the way.
A lot of that, is because I've been writing code for over 30 years, and a lot of my personal process is "muscle memory."
But sure, routine helps. And probably also what you are building. I am mainly working on a big project with lots of legacy code involved, that is just not right. I cannot just fix anything I come across. I would never get the priority things of my list.
This is a good observation, but it's not just engineers: the fact is most people don't like ambiguity, and the more it cuts across org structure lines the less they like it. This is no big deal as long as the org structure lines are well drawn and business are covered adequately, however at scale it also limits the type of changes that can be done without massive pain, and creates a risk when new needs are identified that are not well served by the existing structure.
These fuckers even have a joke about how a bus hits an engineer and no harm is done to the project. How inappropriate is it to make jokes about a bus hitting your colleagues.
Agile was explicitly invented by engineers for engineers, just look at the history of the original manifesto.
One big problem is that it was built for self-managing teams composed only of engineers and established businesses are not built like that at all. There are non-technical people which are necessary and have legitimate business needs. Some of these are managers with power, so of course they're going to (ab)use the process to get what they need.
You can either change the structure of the business itself to be more Agile-like (good luck with that in an established company, especially a non-tech one), or adopt a more realistic posture which invariably involve concessions and deviations from the Agile model, but ends up better for all involved.
Both management and devs alike can be concerned about the bus factor, which falls under fungibility.
Of course, an organization can have (or lack) humanity beyond those three goals. And hire people who have (or lack) the requisite humanity to bring to their role. If someone treats the bus factor or general fungibility casually, that's a problem.
I could be wrong about 'meatspace', but I'm pretty sure that was Ian M. Banks.
I mean, that's because managers do have arbitrary power over engineers in most places. No project planning approach will ever make that go away if it's true in your org. Blaming agile for the inherent broken power dynamic of your company just makes it harder to fix the underlying issues.
For junior people, we'd pair them with a more senior person to help break down work but other than that there was very little overhead.
It seems what works the best, as least for B2B SaaS, is driven more by building a feature that works, instead of trying to hit a date, or stripping the feature down to nothing in order to hit that date.
Sometimes you have to hit a date, sometimes you don't.
Sometimes having something is better than nothing, other times unless you have all the functionality it's worthless.
Sometimes you can know all the requirements upfront, other times they are ambiguous and require testing and failing.
The only way to be wrong is to pick one methodology and apply it to all circumstances. There are times pure agile will work, there are times waterfall will work, and there are times that neither of these are right and you have to do something else.
Hitting a date by striping features, or a feature with fixed scope but no fixed date.
I also think setting dates makes things go slower. We don’t use delivery dates at my company. Instead, we have quarterly cycles. Whatever gets done in that cycle gets done. We only aim to deliver one big feature per quarter, but it ends up being 2-3 because we’re so conservative. This also takes the pressure off of releases.
The good in Agile:
* Think about your processes and your progress.
* Inefficient processes should be culled.
* Overmanagement is bad.
The bad in Agile:
* Complete ignorance of the legitimate needs of everyone in business who is not a professional software engineer (most of the Agile mantras are actively harmful here, and are discreetly walked back as in this entry).
* Iteration is not a value in itself.
* Programmers should be managed, at least so long as the typical corporation has the structure it has, and Agile doesn't provide good tools here (at least none that programmers like...)
And act upon them. I have sat through so many retros which turned out to mostly be about writing a report. Now, retros are something I try to get done as quickly as possible.
Then I realize that my suggestions are ignored and "action items" never have follow up. I revert to contributing nearly nothing. I usually come up with a "what we did better" item so that I don't appear completely disengaged from the process.
There’s also a big push for Lean UX - basically the UX design process squeezed into the dev team’s schedule. Sounds great, but never works well. It’s like trying to complete a jigsaw puzzle a piece at a time without being able to see the picture on the box.
It's too bad that it's mostly advice to managers who are the least likely to read this stuff or take it to heart.
Yeah, I know, that's not Agile according to the Agile Manifesto. Forget the Manifesto. You think the CTO approved an Agile transformation because of a fucking manifesto? NUMBERS. How much money can we save and how much more profitable can we become by delivering exactly the software, and only the software, our users need with ruthless efficiency? This, and ONLY this, is Agile in the enterprise. Shove your manifestos. You have sprint commitments you need to fulfill. Get back to work.
Absolutely! I'll go even farther and say that Agile is actively toxic to software development.
Take the second suggestion, for example, where the author appears to imply that tech debt, test coverage, etc are "2nd rate tasks" yet the speaker in the quote addresses this very point about how Facebook learned the hardway to ignore such things.
Instead of shrugging shoulders and blaming instant gratification, how about taking some measures of the impact that tech debt is making? Are you seeing outages as a result? Are you wasting resources as a result? What kind of cost savings could you expect by fixing it? How many bugs have you released that could have been caught by better test coverage? How much time is wasted on testing that could be automated?
Those are killer KPIs to measure, and extremely satisfying, in my humble opinion.
While its valid to ask devleads to estimate, I want to reach into the codebase and get some metrics. Can you label the functions that are "techdebt"? When did they run ? etc
> I must admit that I have committed this mistake as well.
Is OP implying that the defect is not the highest priority?
In an obesity crisis world aren’t you better off eating one marshmallow rather than two?
We are especially vulnerable to superstimulus (exaggerated signals), which is what makes McDonalds, TikTok or surgically augmented breasts so popular. More sugar, more salt, more silly faces, more breasts. Even if we don't prefer them our brain is drawn to them. They used to be important signals. Youtube video thumbnails almost always feature people making faces, TikTok is short videos of people making faces. It's a race at providing better superstimulus. A lot of our culture these days is a constant bombardment of stimulus and we are not especially adapted to it.
Couldn't agree more. if this trend continues, the only possible consequence is drugs becoming a form of art.
When external stimuli won't do it anymore people will seek to directly stimulate themselves with chemicals.
I think society would also find out that the risk benefit analysis of club drugs and LSD vs. social media and junk food is tilted heavily in favor of the former
Why? McDonalds are not that delicious and I make better tasting burgers at home anyway.
McDonald’s is not the best burger. But for the cost, speed, and effort involved, it’s pretty good.
We could make all kinds of things ourselves but largely we don’t.
For someone in a wealthy and stable environment, it is rational to wait 20min for the larger reward, as there is a high expectation that the promised event will occur as planned. However, in a poor and unstable environment, it is often more rational to take the bird-in-the-hand, as there is considerable uncertainty about whether the promised 2nd marshmallow will actually arrive.
A thing that gets lost in a lot of discussions about Agile, even the ones like this one that invoke the intent of the Manifesto for Agile Software Development, is that there are material advantages to Agile over the systems analysis style of project planning and management. It isn't just mindfulness over following a recipe.
Agile was needed because replanning with complete functional and implementation specs, and complete task estimates and coder assignments needed for a resource-leveled critical path analysis is way too onerous. That lead to not replanning as tasks, knowledge, and goals change, which is worse.
There are tools, like having an MVP milestone, doing decision tree analysis at key milestones, etc. that are compatible with Agile, and there are techniques, especially metrics, that are voodoo or just adornments on Agile-as-management-fad. Knowing why Agile was needed vs what was used before is key to understanding what is compatible, and what is an impediment to agility.
This insight that replanning is easier with agile methods is pretty key.
This means you give up that beautiful "network diagram" CPM schedule estimate with no overloaded resources. But because of the nature of most software development projects, it becomes a burden, or a lie, within weeks.
Of course, it becomes less great when you start getting dependencies between teams and 2 week sprint delays mean that it takes months to get something cycled through different teams.