The Agile Blind Spot (Guest Post by Jurgen Appelo)

Written by Jurgen Appelo Thursday, 16 December 2010 11:47

Note from Mike… After 320 or so posts… this is the first guest post on LeadingAgile.  The idea of having  people do a guest post is a bit odd to me.  LeadingAgile is a labor of love and very personal.  I’ve got a ton of respect for Jurgen, and really admire his work, so when he mentioned the idea… I really couldn’t say no. This is a great post… hope you enjoy!

It’s nearly 10 years that the Agile Manifesto was written, and everybody and their grandmother loves pointing out “weaknesses” in the original document. Allow me to jump on that bandwagon and add my own thoughts to the ever-growing pile.

I believe a “weakness” of the Agile Manifesto is that it doesn’t (explicitly) recognize that all software projects need people being smart, disciplined, and attentive. The “people over process” paradigm is great, until you find out that your team consists of two trolls, a parrot and a hairdresser, and a relatively bright project manager, who happens to be deaf, blind and mute. No amount of coaching will help a team like that to magically self-organize and to deliver a successful product. I call this the agile “blind spot”. Agile (as promoted by the manifesto) is great only when the team is great (or at least good enough). To be fair, the need for great teams is probably even twice as important in non-agile environments, but the Agile Manifesto too leaves the competence issue unresolved…

To address this problem, I usually compare agile management with traffic management. Traffic management is the art of reducing the number of casualties in traffic, despite the fact that most drivers are either dummies, lunatics, or flat-liners.

Wikipedia claims that my home country, The Netherlands, has the lowest traffic-related death rate in the world. Yet we live with 17 million people, and 136,000 km of roads, crammed together in an area smaller than West Virginia. And I know for certain that the drivers around me are not a hair smarter than elsewhere in the world. (To be honest, San Marino and the Marshall Islands have an even better score. But it’s hard to compete with a hill in Italy and some rocks in the Atlantic.)

The Dutch use no less than seven complementary approaches to achieve such a low death rate. The principles behind these methods could be used by agile managers who want to lower the fatality rates among their own projects:

  • Culture: I’ve been told by a good friend of mine, an expert in traffic management, that the Dutch culture is one of the most important contributors to the (relative) safety on our roads. Dutch people care. About their car, their money, and other’s people’s lives. (And in that order, I think.) Translation: No matter what other methods you apply to achieve competence in a social system, in the end it all depends on whether people actually care.
  • Instructors: In the Netherlands, you can only learn to drive with the help of an instructor. Putting a “learning” sign on the roof of your own car, or getting help from your dad, is simply not allowed. For at least 20 or 30 lessons you are instructed by someone who is driven around the city all day by pupils, and who asks big piles of cash for this privilege. (I would demand a similar amount of money if I had to watch the same scenery 40 times a week.) Translation: Teach people how to do their jobs properly. Again, and again, and again.
  • Driver’s license: You must take a test and prove that you are capable of participating in (Dutch) traffic, or else you won’t be allowed to go out on the roads by yourself. Translation: Require that people are properly tested before allowing them to participate in (challenging) projects.
  • Traffic signs: I think we are the country with the most traffic signs in the world. There’s not a square kilometer left that doesn’t have some neatly positioned signs, road markings, traffic lights, cameras, or other regulatory stuff on it. (And when it’s raining even our cows are aligned in the same direction.) Translation: Decrease the chance of problems in your teams by using smart and proactive tools, checklists, alerts, notifications, and other regulatory stuff.
  • Traffic police: Yes, we all hate them. Me too. I paid many hundreds of Euros for speeding tickets last year. (I prefer calling it the “speed tax”.) Translation: Have a process manager walking around whose job it is to take samples of the results in your projects, and check whether quality output is being produced. And if not, well… you decide.
  • Car horn: This is a favorite part of my car. Letting other people know that they are endangering either you or someone else is crucial in keeping the number of fatalities down to a minimum. Translation: Make sure your team members have the guts to tell each other how to improve their daily work. Let them honk their horns, or give each other a finger. Figuratively speaking, of course.
  • Government: When everything else fails, the government will step in. They investigate what went wrong; they make new rules or constraints; and they decide who’s right and who’s wrong. Translation: Management will need to clean up the mess.

Smart, disciplined, and attentive people don’t need a driver’s license, or traffic signs. They don’t need to be taken off the road by the police, and others don’t need to scold them about their dangerous behavior. They simply do their jobs well. And that’s what most agile development methods assume. It is their blind spot. But the world isn’t perfect, and neither are most drivers, sorry, employees. Therefore management has to figure out how to address the blind spot, and how to drive safely.

This article is an adaptation from a text out of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.


5 Comments

  1. Sachin Kundu   |  Saturday, 18 December 2010 at 12:39 pm

    Wonderful analogy Jurgen, I enjoyed reading this. I don’t think that it is a weakness of agile manifesto that it does not mention people factor. I think thats a given for any successful project in any field. If you don’t have the right people for the job then no amount of coaching or tools can get things done,

  2. XebiaLabs   |  Monday, 20 December 2010 at 10:13 pm

    Thanks for your opinion on the state of Agile, Jurgen. One other common issue that developers have with Agile is that it can often be too productive. By this, we mean that the Operations team members often can’t keep up with the faster iterations that the Development team is delivering. Luckily, deployment automation software can help even the score by eliminating time-consuming, manual work and allowing Operations teams to keep up with deployments. Would you agree that deployment automation is an extremely effective solution for this common problem?

  3. Paul Leclerc   |  Sunday, 26 December 2010 at 11:04 pm

    Mike… Thanks for bringing on Jurgen as a guest. Mentioning the “elephant in the room” about agile needing skilled people is often glossed over. Sure agile will uncover those who don’t have the skills needed but in most large companies, you can’t just kick them off the team.
    I look forward to reading Jurgen’s book and thanks for bringing it to our attention.

  4. Gillian Clark   |  Thursday, 06 January 2011 at 3:37 am

    Excellent article which highlights that agile is not a silver bullet, especially if the gun is being held by a ‘dummy, lunatic, or flat-liner’. The next question is that if you’re team is not competent enough to be ‘truly agile’ do you

    a) go back to traditional methods where developers can hide behind the process
    b) lower your/the business expectations of what benefits agile can bring.

    Personally I’d go for b), I’d rather see what is going on in a project, even if I don’t like what I see …

  5. Team Rooms Breed Highly Productive Agile Software Development Teams | Agile Development   |  Wednesday, 30 March 2011 at 8:51 pm

    [...] However, no matter how good your methods, if you do not have the “horses” — i.e. bright and dedicated team members — you will not have a top notch team. Good teams need good people. [...]

Leave a Comment