Jun 7, 2007 6:27:28 AM
Given that my team is one of the ones charged with implementing Agile development practices, I was very interested in attending Erik Doernenburg's talk, not to look for signs of failure, but rather to see what I could do to help us succeed (and to get a better understanding of Agile from someone who is an expert in the field). Here's a recap of the talk, which was originally advertised here: http://skillsmatter.com/why-agile-teams-fail. I thought it looked good, so I signed up and went with a friend and four coworkers.
The location was in an ultra-cool office building near Farringdon. The talk was a bit too long for the time - don't go without having some dinner! A lot of the reason why my notes are sketchy at the end of the talk was because I was too hungry to pay proper attention. I also found a lot of the audience members just talked too damned much, and I got bored listening to them prattle on.
First, Erik emphasized that Agile isn't a process designed for failure, then quoted a statistic that while 40% of Agile projects succeed ... only 15% of waterfall ones do!
Next, Erik went into the body of the presentation, which was a "bottom ten" list of reasons while Agile projects fail, in no particular order. I'll repeat his order, and the content as I recall it.
10. Believing Myths, such as ...
A. No documentation is required (it's still vitally necessary, but you write it as you need it, and only write what is useful and what your project needs).
B. Agile is only good for small projects.
C. Agile is "cowboy coding" (this means there are no controls and people just do whatever they want to - an incorrect understanding of Agile).
D. Agile projects have no need for analysts/testers .
9. Misunderstanding "controversial" terminology
I'll summarize this one, but basically, Agile has some key words it uses that have a special meaning that can be misunderstood by people who haven't studied it. For example, the original name for "Agile" was going to be "Adaptive," which captures the spirit of flexibility and learning it's supposed to enable, but since they didn't use that name, people hear Agile and mentally translate it as meaning "faster and with less overhead" (per the Dilbert cartoon here http://www.vlsi.informatik.tu-darmstadt.de/staff/mjung/index.html ). Here are some of the words he pointed out as being liable to misinterpretation.
Actual Heard As
Stand up Not at a keyboard
Unit testing Extra code
Extreme Out of control (Cowboy)
8. Missing key roles
Another thing that can happen is people think that Agile means that all you need is developers. This is very much not true. Key roles not to be forgotten about include iteration managers, analysts, and testers. Erik also pointed out that while a sprint for development takes place, the analysts and testers continue their work, but oriented on a different sprint than the developers. He provided a table that looked like this (the content is exactly as his was but I can't draw a table in HTML to save my life):
Sprint number -> 6 7 8
Analysts 7 8 9
Developers 6 7 8
Testers 5 6 7
He noted that while testers would do a little testing during the developer's current phase, this was only enough to verify that the developers had completed their "stories" for that sprint - the body of testing on a given sprint would take place when the developers had started on the next sprint.
He also drew a burndown chart that showed the number of total sprints for a release and the number of items to be completed, and said that after just one or two iterations you could see if you were going to be able to complete all of the "stories" initially planned for that release, and then warn business owners in plenty of time for them to make (and communicate) good decisions about whether to change scope or change dates. "Do it early so that you can give them choices!" was his advice.
7. Overdoing it.
Unfortunately my notes are slim at this point. Overall, the idea was do only do (code, write, design) what was useful and not so anything just because "this is the process here" or "we've always done it this way" or "this bit of code is really neat and look how I can extend it to infinity." Really consider utility!
A. Every document must have an audience.
B. Every practice must solve a problem.
C. Drop anything that does not add value (but you must have experience in order to make good judgments on this).
D. Don't micromanage people.
E. Don't draw a state diagram.
6. Cherry Picking practices
Erik's point here was that some companies want to use just part of the Agile methodology, expecting they'll receive its benefits without actually buying into the whole package. While Agile is by its nature adaptable, Erik said that it's better to start off with the established set of practices. Here are his suggestions for getting it right.
A. Try the methodologies once by the book.
B. Try each of the practices for three iterations.
C. Test every change for three iterations.
D. Only make changes when you have the experience to understand what a given practice is for.
E. Any decision on cutting/changing practices should be made by the people most involved in the project.
5. Lacking Discipline or Courage
Failure of "Agile" is caused because organizations don't get 100% behind the change. It upsets the apple cart too much, and while a company wants to be successful, they "clutch agile like a straw," then blame developers for the lack of success when it's the company that didn't provide the support they needed to do it. His advice: Don't be afraid to change.
A suggestion he made was to use a "five star retrospective," where the various practices used during a given iteration are reviewed under the following criteria:
Start doing ...
Stop doing ...
Do more of ...
Do less of ...
Keep on ...
4. Failing to ask for help
This can be at the individual level but can also be an organization that doesn't get advice from experienced Agile evangelists. Agile, he said, really isn't something you can just pick up from a book, most of which are merely one person's view on what worked for them. He used the metaphor of the "cargo cults" of the South Pacific, who thought that cutting down trees and putting a person in a tower would cause great silvery insects to fly from the sky and drop boxes full of good stuff down upon you, just like it did for the American Army in World War II. Just following the forms without understanding the "why" will not get results. His advice: get experienced people and listen to them.
3. Using iterations that are too long
I've added my notes in parens - he was talking quite quickly at this point.
A. One week is about right - maybe two.
B. This has nothing to do with velocity and everything to do with keeping people moving in the same direction.
C. Developers require direction (his quote, not mine!).
D. No time to get sleepy.
E. Faster teams need more tweaking (you need to constantly readjust work when so much is going on at the same time was my understanding).
F. (Easier to undo mistakes.)
G. Planning is less painful (during the weekly "story assignment" meeting, I believe).
H. Tuesday to Tuesday is ideal for sprints.
He then went into a detour about "stories."
A. They should be small enough to show someone
B. It's okay if they can only be understood by another techie (for stories like "build a SOAP interface for X").
C. Try the "happy path" to make it smaller and make error handling a different story.
He also mentioned that refactoring and bug fixing could also be stories, something I'd never considered before.
2. Failing to find a good sponsor
The sponsor is the business owner behind the project. It requires a lot of input to make Agile succeed from all levels, but not everyone is prepared for the commitment!
A. Find a good customer. (If you are forced to implement everything included in the contract because "it's in the contract" even though the development has shown that it doesn't make sense, you do not have a good customer. This is also contrary to the principles of the Agile manifesto.)
B. Have a supportive sponsor.
C. Look for excitement around Agile.
D. Look for past failure.
1. Failing to rally the team
Make it fun! He used the example of a Nabaztag rabbit (http://www.nabaztag.com/en/index.html) which his team uses to show the status of the build. When a build happens, the rabbit's ears rotate. When the build is successful, the rabbit's ears stand up; when it isn't, his ears droop and his belly is red. Erik said you could do something similar with lava lamps, etc., but the point was that it was fun but motivating - when the rabbit was sad, the developers really wanted to see those ears perk back up!
1. The team will make or break the project. (So you want to make them feel empowered and motivated.)
2. Good leadership is critical.
3. Environment is critical.
4. Support for the team is critical.
5. Team dynamics are critical.
Let me know if you have any questions, but I warn you that I did put almost everything in his presentation that I wrote down in this email (other than some comments about pair programming and a few jokes), that I didn't write down everything, and I am by no means an Agile expert! But I left the meeting feeling very motivated to see my project be a success, and I felt like I better understood what I would need to do to have it succeed - as an Agile project. I hope this is similarly helpful to you.
[more]
Posted by webcowgirl @ Jun 7, 2007 6:27:28 AM [Link]