Comment (0)

–

Remember the Monty Python crunchy frog sketch? (If not, you’re in luck because you can watch it above.) Now, the final section is particularly noteworthy:

Officer: Well, why don’t you move into more conventional areas of confectionery? … I mean, look at this one, ‘cockroach cluster,”anthrax ripple.’ What’s this one, ‘spring surprise’?

Shopkeeper: Ah, now, that’s our speciality, covered with darkest creamy chocolate. When you pop it in your mouth, steel bolts spring out and plunge straight through-both cheeks.

That is what Agile is like to me. In AgileLand, everything is sweetness and light. Agile has all the answers. Everything works. Agile is utopia.

I’ve taught enough Agile introduction courses to know this is so, and pushed it, too. "There is no scenario I can’t fix in the classroom with the application of the right Agile principles, tool, or mindset." And if I can’t, well, in that case, Agile is helping you see the problem more clearly, and you have to find your own solution.

Honestly, though, part of the appeal of Agile is that: Agile is a damn good story. Agile paints the picture of a better world, and so it should.

Particularly when delivering an Agile training course, I see my role as two fold:

1. Impart enough information so that teams can actually try Agile
2. Energize people to want to try it this way

The only problem is that there are some dirty little secrets in the Agile world that don’t quite fit into this picture.

First up is micromanagement

As I said in Devs Hate Agile, the Agile toolkit can be used for good or evil. If someone wants to be a micromanager par-excellence, then Agile — and particularly Scrum — make a great toolkit for micromanagement, too.

The intention behind the Agile/Scrum approach is to give those who do the work the tools and approaches to take control of their own work. When they do so, great things happen; the workers control the means of production! However, those same tools can be used very effectively by those who would control the workers.

What micromanager would not want every team member standing up to justify themselves at 9am each morning? Surely a micromanager would want working software at every opportunity? And if you fail to deliver working software, then…

In part this is because:

Agile is a great tool for apportioning blame 

When builds fail, you know who did the last check-in. When tests fail, you know who broke it. When cards don’t move on a board — sorry I mean Jira — then the powerful can hone in on those not pulling their weight.

Kanban is even better than Scrum here. I remember one project manager who used the Kanban board we constructed (26 columns!) to demonstrate why everybody apart from him was slowing work down. Try as I might, I couldn’t get him to see each of the problems to be worked on. To be fair to him, he was the product of a system where almost every step was undertaken by a sub-contractor; he had no power to change or reward sub-contractors, only to whip them.

Both these points illustrate the next dirty little secret:

You don’t need to do everything

Simply holding stand-up meetings and end-of-iteration activities is a massive improvement for some teams.

Developers who adopt test-driven development will produce fewer bugs and waste less time in the debugger, and the testers who come after them will spend less time reporting bugs. Thus, fewer bugs will need fixing and schedules will improve.

A Kanban board with WIP limits will improve workflow even if you do nothing else.

Yes, if you do every part of Scrum, things will get a lot better. And if you do every part of XP, the total benefit will be better than the sum of the parts.

Part of the genius of Agile is that it can be implemented piecemeal. But that also means organizations and teams can stop. I’ve seen this a number of times: I introduce a bit of Agile, the immediate pain is relieved, and the company loses the will to go further and improve more.

After all, who am I but an external consultant to tell them they could do better? Once the pain if gone, the need to change goes, too.

Agile project management shouldn’t be a thing

Many readers will know that I have been active in exposing the dirty secret of Agile Project Management — i.e. the idea that Agile and the project model (aka project management) can work together.

Sure, they can work together, but why? What is the point? Why go to the trouble of integrating Agile and Project Management?

Once you start working Agile, the project model looks absurd — hence my #NoProjects — and why so many people have arrived at the same conclusion about projects independently.

Most companies don’t want to be Agile

Companies that introduce full blown Scrum — including self-organizing teams — risk destroying themselves. In traditional, top-down, hierarchical companies, Agile and self-organizing teams must be contained, otherwise it will destroy the whole hierarchy. That is why banks struggle with Agile:

The chocolate on the outside is really nice, but sooner or later, what they are eating runs up against what they are.

There is no one true way

Finally, you might notice that in this post — and, indeed, in many of my other posts — I don’t agree with other Agile advocates. Go and read Jeff Sutherland (I don’t agree over self-organization), Mike Cohn (I don’t agree over stories and points), Keith Richards (not the rolling stone, the APM man, I don’t agree over projects), Jim Coplien (he doesn’t agree over TDD), Joanna Rothman (we don’t agree on stories), Dan North (we don’t agree on teams), and just about anyone else, and you’ll find I don’t agree 100 percent with anyone.

True, I make a point of being a contrarian. If you don’t believe me, you should really go and read my "How I learned to Stop Worrying and Love My Own Version of Agile" article.

But the thing is, none of these people agree with each other. Everyone in the Agile community interprets it slightly differently.

I feel sorry for newcomers to Agile who expect to read the one true way, but I also see none of us "gurus" wanting that because we want variety and experimentation. And perhaps that is why one-size-fits-all Agile scaling is always doomed.

Further (Monty Python-related) reading, because you’re welcome:

Blue. No, Yellow! Monty Python on the Marketing Bridge of Death

This Swearing Roomba Is What Python Was Born to Create

Comment (0)