“All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.” — Weinberg G. M. (Project Mercury)
I think many of the agile principles remain largely unpalatable to your typical command & control org structure.
One of the main premises of Agile, is letting people closest to the work decide how they want to work.
Instead, in many companies, the org co-opted the meaning of Agile for its own agenda. The PMO got what it wanted, putting heavily gated process on top of Scrum. Why Scrum? Because its push, of course (instead of pull).
At the moment, my org is adopting SAFe, and PI planning, which has devolved into quarter long waterfalls for projects. We just use Scrum as 2 week waterfalls in the quarter waterfall.
Probably because for most of us they never existed - and yes, of course I mean "pre-agile".
This whole "before Agile it was all waterfall and no one could conceive of anything differently and oh my brothers, let me tell you what a nightmare it was" cant is just that - a cant, something people like to repeat without thinking about whether it has any actual validity in, you know, actual reality. In other words, a myth.
There have always been good shops and bad shops; but like the sibling commenter said, (in the better shops) people have been working iteratively for decades and decades before the Agile Manifesto descended to earth on a ray of light, accompanied by angels.
But where agile really shines is when the problem is poorly understood and the solution not well defined.
Which problems people, again, had already been solving for decades and decades before the AM.
Such negativity
"Negativity" is not only an appropriate, but a healthy and necessary response to the never-ending stream of cargo-cult tripe and talking point nonsense that is Agile.
Agile introduced tactical planning and dropped precise schedule estimates, which did not hold up anyway.
If more Agile proponents would start with that instead of leading with the collaborative aspects of Agile, and drop the Scrum jargon, they would be better understood.
Making software is not like most other projects. Many more new problems to solve because if you already solved it, just reuse the code. That has practical consequences in project management, specifically: iterating toward the goal.
Collaborative task assignment for each iteration is important. But that's not why iterating toward a goal is how to do software.
I did. Scrum and "agile" are far, far worse, based on what I've seen and experienced. Those "bad old days" were heaven compared to the bizarre approach currently in vogue. I will be very happy when this fad passes as well.
> But where agile really shines is when the problem is poorly understood and the solution not well defined.
That's the problem...people think that you can just use "agile" and not worry about understanding the problem and developing a solid solution. You just start slamming out code and checking back with the customer, wasting huge amounts of time and effort.
See Barry Boehm's https://en.wikipedia.org/wiki/Spiral_model for what has already been done correctly.
> Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach.
It does not. It is micromanagement ritualized and it somehow leaves both customer and workers unhappy.
The key thing a "Knowledge Worker" needs/demands is Autonomy over his own Work/Decisions (within the context of the larger problem). In the old days, we had the Freedom along with the Accountability. What Agile/Scrum has done is taken away our Freedom but by micromanaging our day-to-day activities has increased our Accountability. This is completely unjustifiable and unacceptable.
PS: An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only - Bjarne Stroustrup.
Consequently, you felt like you have done and achieved something. You also could create something coherent. Also, over time you became better and better at the thing you was doing. You was thinking about module or project as a whole.
With agile, I feel mostly like cross between factory worker middle management politician. Every little detail has to be negotiated with multiple people and half success is guessing what is on their minds. You work on tiny tasks. You dont get sense of achievement, you just use your hammer to put in nail here, then paint a bit over there.
Also the team itself should be very autonomous inside the organization as much as your context allows. In fact, the company I work for had fully independent teams in startup mode for so long, that eventually they started to step on each other toes, there was very few alignment. As company grew, more alignment and therefore negotiations started to be needed but I don’t see much way around that other than staying small and horizontal (which I like too). Still, on parts of the company on “exploration mode” (from Kent Beck’s 3X model), teams still remain very autonomous
As for the small tasks, I see them as a way exactly to promote a sense of achievement, the team is responsible for this big chunk of work and you should be able to see very clearly how things are moving forward. Sure, if you lose connection with the bigger picture because you or your team does not have enough autonomy, then something is wrong and you need to fix it, otherwise you lose this effect.
Otherwise said, all those decisions are done by committee. None of them can be done by any employee autonomously and no employee gets to have responsibility. You never do those things nebulous, notion of "team" does. But team is not you, it is group of people. All the situations you described are negotiation between many parties situations.
Also, micromanagement or decisions monopolization can be done by anyone on any level. Many developers love to do so - and exactly these do love agile, because that gives them cover to railroad everyone else. Agile is really big on making PM or management enemies. It does work to some extend, common enemy does bring people together.
> Also the team itself should be very autonomous inside the organization as much as your context allows.
And no single team member has no area of responsibility or autonomy. And that is the thing - if you like to dominate and influence other people, agile gives you plenty of playground. If you like to throw your weight in the meetings, great. But if you dont want to do that constantly all the time, you are expected to be passive follower with no space for any autonomy, mastery nor accountability.
> As for the small tasks, I see them as a way exactly to promote a sense of achievement, the team is responsible for this big chunk of work and you should be able to see very clearly how things are moving forward. Sure, if you lose connection with the bigger picture because you or your team does not have enough autonomy, then something is wrong and you need to fix it, otherwise you lose this effect.
Note how it is still the "team". You don't see nor mention any individual. No individual at that team achieved anything personally. Individuals almost don't exist. They did not made single tiny decisions that would not been discussed to death with five other people. For a methodic that is supposed to favor individuals, there is literally zero concern for individual or human psychology. The only interest is in group.
It also happens on scrum teams a lot, the engineer the built certain part of the system is the only one to ever take tasks related to it and the only one that knows how to fix it, so when they are gone you have to deal with their mess
On XP pair programming solves that very nicely, with a lot of comradery, but then you may also argue there is not enough individuality
No. That is literally extreme with zero individuality, zero autonomy and so on. Yes, there are extremes that are even worst then average in agile systems. But the extreme existing does not mean the average is somehow good.
> The small decisions should be made by the individuals of course, as group decisions are too expensive, but the bigger ones should be taken by the team, where it pays off, or at least a pair. I’ve dealt too much with bus factor problems in the past to want fully individual systems
Which small decisions are made by individuals in agile system? I am not aware of any, unless one is actively hiding what he is doing. That is my point. There is no autonomy, no mastery no accountability.
You said you was surprised that I found agile less motivating due to lack of above. And now you are telling me that there are systems which are even worst in that regard. Yes, I know they exist. And almost no one wants to work in such teams.
> It also happens on scrum teams a lot, the engineer the built certain part of the system is the only one to ever take tasks related to it and the only one that knows how to fix it, so when they are gone you have to deal with their mess
And now in agile system, I have to deal with everybody mess all the time. Because there is never a point in time when I know the part of system I work on well. I dont know what the system I work on is supposed to be doing. No one knows. So we all muddle through.
Very right! They were never true; mere blame-game when they screwed up something else.
>It is micromanagement ritualized and it somehow leaves both customer and workers unhappy
Well Said! Even stronger : A Ego/Power trip for people who can cut it as neither Developers nor actual Managers :-)