boogdesign posts

Longer posts on standards based web design, portable web development and Linux, intermingled with some stuff on my other nerd interests.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now
« Google Developer Day 2007 UK - Morning Sessions :: Scriptaculous Draggable and Z-index »

In-the-Brain of Erik Doernenburg: Why Agile Teams Fail

06/06/07

11:55:13 pm Permalink In-the-Brain of Erik Doernenburg: Why Agile Teams Fail

Categories: General, Management and Communication

Review: Why Agile Teams Fail at Skills Matter, Sekforde Street, London 18:30 to 20:30

Erik started with a discussion of what motivates people towards agile practices. He quoted a recent study (I'm not sure, but I think he meant this one from the IEEE) which arrived at the conclusion that 15% of 'waterfall' projects 'succeeded', whereas 40% of 'agile' projects 'succeeded' (gratuitous quotes because he wasn't sure what the words were actually defined as in the context of the study). It's nice that agile practices can result in such a big improvement in success rates, but Erik didn't think this was the main reason why they were embraced, he thought the motivation came more from self interest as a result of the threat of outsourcing. If coding is a commodity, then it can be outsourced, and it makes sense to outsource to the cheapest supplier. But if software development is a process which relies on regular face to face meetings between developers and customers (ie. agile) then that's much more difficult to outsource.

After this short introduction, he had ten slides for his top ten (in no particular order!) reasons why agile teams fail. It's fair to say that a lot of the reasons, like agile practices themselves, reinforce one another:

#10 Believing in Myths
There are a lot of myths which have built up around agile methodologies - pairing costs twice as much; no documentation is required; agile practices are 'cowboy coding'; Scrum is agile. Erik went into each item one by one and dismissed them, for example reducing the amount of documentation is not the same as having no documentation - just produce the documents which will actually get read, there is more to just pair programming than just one person doing nothing and if you're following a recipe out of a book then you're not really doing agile. His main point was that believing in the myth is likely to cause the myth to become reality.

#9 Using Controversial Terminology
Common agile buzzwords are actually quite frightening to managers - say 'extreme development' and they hear 'risk'. The founding fathers of the agile movement chose the terminology quite badly from the viewpoint of selling the practices to conservative middle management (originally they wanted to call it 'Adaptive Development' but apparently there was a product out which already used that name). The buzzwords don't really capture the value proposition involved in the practice, for instance if 'pair programming' was instead called 'constant code reviews' there would be less opposition to the practice. Unit testing is not extra code which has to be written, but is actually part of your software design and specification, and one of it's main benefits is encouraging you to think about the external interface of your class before you implement it, reducing the risk of producing a tightly couple class structure without realising it. There was a short discussion on refactoring, how do you justify to a manager re-writing code which already works instead of writing new code? Erik thought this was a result of a blinkered view of the software development life cycle - in the real world software is never finished, and maintenance is important. He also pointed out that if you have separate development and maintenance teams then there's no incentive for the development team to produce maintainable code. The main point of the slide was you don't need to use the standard terminology and frighten off managers, find your own terms which describe value proposition involved in the practice.

#8 Missing Key Roles
Agile development doesn't mean you can do away with business analysts and testers, they are still needed just as much as developers. Erik had a slide which showed how a typical one week iteration would actually last three weeks with the involvement of the full team. While the testers worked on iteration six, the developers could be working on iteration seven while the business analysts are preparing iteration eight. From this slide we got into an interesting discussion about how to estimate how many stories should go into an iteration, Erik talked about 'T-shirt sizing' for stories - triage into small, medium and large then working out how many stories you can fit into the next iteration from how long, on average, it took to do each size of story in the previous iterations. He also talked about having 'iteration level stories' and 'release level stories' as well as how to stop testers (working on the previous iteration) destroying the momentum of the developers (working on the current iteration) - basically do the small ten or twenty minute fixes but write up new stories for the more involved defects for consideration in a future iteration.

#7 Overdoing It
This echoed an earlier slide, so I'll just quote it:

  • Make sure every document has an audience
  • Make sure every feature solves a problem
  • Drop anything without value
  • Don't micromanage
  • Don't draw a state diagram

The bottom one was slightly tongue in cheek, but the overall point was don't do any unnecessary work which no-one is going to look at.

#6 Cherry-picking Practices
The agile practices support and reinforce one another, you don't gain much benefit from only doing one or two of them. Having said that, the point of agile methodology is to adapt it to suit your environment, but that shouldn't be haphazard. Decisions should be made by the most involved people and you should stick with your changes for at least three iterations before evaluating whether or not it's working for you. If you flip flop back and forth you only end up invalidating your tracking data.

#5 Lacking Discipline or Courage
Following on from the last slide - if you don't commit fully to agile practices you're not going to get the benefits. Skipping writing unit tests can be good in the short term, but makes refactoring harder and means you're likely to miss some of the effects of your later changes, having the discipline to stick with it will reap rewards in the longer term. Similarly, have the courage to admit when something isn't working and change it.

#4 Failing to Ask for Help
Again following on - don't be afraid to ask for help (and not just from Erik's company, ThoughtWorks!). Experience counts for a great deal in agile methodology. There's a reason why the master-apprentice model of passing on expertise lasted for a long time, and it's only recently that we've started to entertain the notion that we can learn everything we need to know from books. Remember, most process books are describing what worked for the author, not necessarily what will work for you.

#3 Using Iterations that are Too Long
The key feature of an iteration is not how much you can get done in one, but the fact that it offers you a decision point. Nothing to do with velocity, everything to do with direction. If you have three month iterations than you only get four chances a year to change direction, and if you've spent two months going in the wrong direction that's wasted work. Having said that, if your average story takes four days development time to complete then one week is probably too short - the keyword, once again, is adapt.

#2 Failing to Find a Good Sponsor
There's no point even attempting agile methods if there's no support for them higher up the management chain. The environment needs to support it - from basic things like build servers for continuous integration to things like having desks where it is easy for two people to sit and work together without getting disturbed or disturbing others.

#1 Failing to Rally the Team
In this last point Erik talked about some of the fun things you could do to keep the developers interested, this focussed around lava lamps and wireless bunnies attached to build servers, but the general point was to ensure everyone was having fun and stayed committed to the project. If you have a disinterested development team then no methodology is going to save your project.

An excellent talk and discussion, the audience really added value to the presentation with their questions and comments I thought, and Erik really encouraged this level of interaction, 5 out of 5. [Slides]

Technorati tags for this review:    

Tweet this!
PermalinkPermalink

Comments:

No Comments for this post yet...