Agile at 20: The Failed Rebellion

Agile is like a perfect example of a lot of things. Publishing a "manifesto" makes the revolution analogy on-the-nose.

Dissident manifestos tend to share a the same failure point. They're heavy on critique of the system that they want to overthrow, hand-wavy on the system that they want to enact.

The Communist Manifesto, to pick on the obvious example, is mostly about capitalism, other (wrong) versions of socialism.. notably reactionary socialism. It's also about the struggle to bring about revolution. There's surprisingly few paragraphs about what communism will do differently, once the revolution takes place. Liberal revolutionary manifestos was similar, with French and american revolutionaries settling (or not) on a system of government only after overthrowing monarchy.

The agile manifesto does outline a lot of how agile works, but the most compelling part was its description of "waterfall" and all its ills.

Liberalism and communism, in their idyllic literature, never really contended with the fact that these were alternative methods of "ruling over a population." Agile never contented with Agile was as a people management system. Well... Agile is a way of telling developers what to do. It is a people management system.

Where its completely unlike the political analogy is that agile was derived from working systems. It wasn't just an idealization. Ironically though, it ends up in the same place. What worked well for particular teams became the ideals.

I think the ultimate stinker though, was the "political economy" of agile. A company where everything works great isn't going to tear out their process and bring in consultants to implement a new management system. It's companies that are failing to produce software well that do this.

Exactly I did a couple of very early agile projects for BT in 94 One using RAD/DSDM and one using a waterfall design with a RAD development phase

>They’re purposely ill defined.

Yes they were. The cynical side of me says that this was because they were purposefully trying to create a rallying cry or something akin to a religion to better sell their wares and were unconcerned about the fallout that would ensue.

The less cynical side of me says they did it because they came up with "extreme programming" and knew that a lot of it was kind of bullshit, disagreed with each other on the details, but wanted some way to push people in "that sort of direction".

The net result either way was... well, a kind of religion.

>You also belittle scrum for becoming too specific.

No, I didn't belittle scrum for being specific. It's one of the good things about it. It is, however, a specifically defined bad way of running a team. We do need designed processes as specific as scrum, that are less one-size-fits-all and that have a more systematic and refined approach to software quality, estimation and design.

"Scrumban" is definitely an improvement, but even that is still lacking.

I'd like to see software team processes treated in many respects as a kind of "software to run teams", specifically meaning:

* That it gets iterated frequently and responds to feedback at every level (not just team, but philosophically - by its founders).

* That it's clearly and precisely defined.

* That there are a variety of different config switches depending on circumstances (e.g. number of people, skill distribution, are you building CRM or flying space rockets, etc.).

* That the individual pieces (e.g. retros, sprint planning) can be chopped and changed and upgraded/iterated on individually and yet still couple to each other sensibly - akin to the UNIX philosophy.

>Knowledge work is immaterial and should have no prescribed rails

No, anarchy is no good either.

> If work activities is about titles ...

It isn't, and I'm not going to go there. But discussion about work activities does need appropriate and accurate labels, for it to be effective.

> So if that means more people do "management", in a context where this is beneficial, then... good? What is exactly the problem?

Who said it's not good or that there's a problem? I didn't.

> You think they are paid too little? Maybe, but then it switches from a work methodology to a salary negotiation problem.

I don't know what I wrote that leads you to believe this, but I said nothing like this. You seem to be reading too far into things I wrote; or worse, things I never wrote.

----

To try and clarify what I meant and where I was going: I was talking about accurately identifying the work that actually happens. Specifically, I was trying to show my parent commenter, ipaddr, how their erasure of such work leads to poor results for everyone involved, including the people trying to even talk about it.

I'm not trying to argue for a better salary or title — I've already got too much and too many of those, as you hope. But I've seen this very discussion happen too many times with clients of mine, with the same devolution. People think their problems will be solved if they get a good "PM". If said PM lacks technical background, they think they can just pair them with a good senior engineer and all will be good. I've seen this fail enough to know that's not how it works; and not because the senior engineer wasn't "senior" enough or "good" enough. As I said elsewhere[1] in this thread: There does exist a big difference between "lead or senior developers" who are good at development and those who are also good at using their technical knowledge to manage a team's work. A non-technical PM lacks that essential latter part, and if they have to rely on a "developer" to step up and fill that role, they're still a PM, but they're not the sole person doing PM any more.

Failure to identify when there's more than one person fulfilling management responsibilities can and does lead to poor planning and hindered execution.

1: https://news.ycombinator.com/item?id=27947644

Co located teams is what you really need (sorry WFH fans)