Agile Failures
I was pointed towards this talk given by Joe Rainsberger at the Agile 2007 conference a few weeks ago. The handout sums it up pretty well. Rainsberger is an experienced Agile coach and admitted Agile zealot. Given his good list of mistake examples, one is left wondering if he has ever been on a successful Agile project. And further, Rainsberger is a leader in the Agile movement and even he had trouble. What about the average Agile practitioner? Surely they must be having some problems too.
In his concluding paragraph, Rainsberger says:
In 2007 I realized that I had spent most of the XP-era of my career inadvertently, but consistently, forgetting about the people involved. I demonstrated this attitude by pushing ideas on them, believing the promise of XP over observing how people react to trying XP, emphasizing learning the practices over introducing what the team needs most, and perhaps most notably by assuming that everyone would be happier if they delivered software more effectively.
In short, he was apparently ignoring the context in which he was working. He was ignoring the impact that XP techniques were having on the project and the people he was forcing them on. Not surprisingly this led to some project failures. And now he is talking and writing about it. There may be some hope after all.
on September 8th, 2007 at 12:23 am
I wouldn’t say all these mistakes he’s suffered are a sign of problems with the Agile methodology. I’d say it merely shows that whatever method used to develop software it’ll come across that same set of weaknesses and difficulties as any of the numerous failed IT projects undertaken - the human element. However, these mistakes aren’t to be feared - they’re to be doubled to paraphrase a very wise man. In the failures you have a great opputunity to learn and I think agile development lends itself to the flexibility and unpredictability of human nature very well and so it’s most uniquely placed to adapt and strengthen rather than be cursed to repeat.
on September 11th, 2007 at 6:03 am
I think that this is courageous from Joe Rainsberger to look back at the problems met as an agile coach and to admit them publicly. I think he could have faced the same kind of problems trying to implement any other change in activity or tool in an organization (and this is nothing personnal against him), but this is true that the fact he was trying to implement an agile approach adds a little bit of irony to the story.
on September 11th, 2007 at 6:13 am
All true. But this example does show, once again, that Agile isn’t the panacea that some would have us believe it is.
on December 25th, 2007 at 9:11 am
There are those who would have you believe Agile is a panacea? Are you sure that’s what they’re doing? What did you see, read or hear that led you to believe that?
I am a believer in XP: I think it’s an excellent set of rules to help people start thinking about how they produce software while still actually producing it. I have always believed XP to be, all things equal, a great place to start learning. Does that necessarily mean I believe XP to be a panacea? What else could it possibly mean?
on November 17th, 2008 at 2:03 am
My personal experience with XP is non-existing. However, I don’t believe it to be much more than hype. I got to this conclusion based on observation of others, doing or trying to do SCRUM and XP.
One of the articles stated that while more systematic, less iterative and more up-front planned ways of doing things emphasize predictability, agile methods emphasize adaptability. I can understand this. Maybe 80% of all code written is contract-based. Customers always ask for predictability, and budget issues are usually quite important. You decide what works best, for these 80%. Agile methods can’t claim the remaining 20% either: there are other dealbreaker conditions to be met which are not met in most cases. For instance team structure: in order for agile methods to work, you need a team of quite skilled, more or less equally good programmers. Which is seldomly the case in real life.
Another argument for agile methods is everchanging requirements. IMO, this is shaky ground. On one hand, in my experience requirements don’t change often - it would mean that company change the way they are doing business similarly often. Only, some programmers/companies have trouble believing that requirements gathering is the most important phase in a software project. When it turns out they did a messy job at gathering requirements, they pretend requirements are changing, so agile methods are better suited for them than planned approaches. In other words, let’s fix the problem in some other place than where it is - instead of requiring the business analyst (or whoever is in charge of gathering requirements and agreeing on them with the customer) to do his job properly, let programmers iterate until they drop dead before something usable can be shipped.
The biggest problem I have with agile methods is documentation. Agile advocates argue that the code is what counts, and systematically downplay documentation. Clearly, they don’t live on the same planet as I do. It often happens that a team does maintenance on an application which was written by others. Programmers come and go. In spite of advocating weak code ownership, agile adovcates don’t account for such situations. It is IMO plain stupid to expect one team to get into foreign code without at least some documentation. While well written code might communicate intent on a low level, and structure on a higher level, it often does not communicate what’s essential for developers to get to do the right thing: the higher level intent of the application. Agile advocates will counter and say that agile methods don’t say not to do any documentation at all, but just to do the right amount. That might sound right, in their world, but what I could notice in my world is that what XP-ers usually see as just enough is nearly nothing. Furthermore, in agile methods documentation is not intended to be maintained. Writing it and not maintaining it is quite the same as not doing it at all, from the point of view of maintainability of the application across different generations of programmers.
The second biggest problem I have is the time box model. Heck, they pretend to empower people, yet they are more deadline-fascist than any planned approach I know of. Not only that, but they impose regular, multiple deadlines on people, some methods more than once a month. Someone told me this is a stupid view of agile methods, because the team decides what the length of a cycle is. Which is even worse: instead of doing your planning of milestones on a case by case basis, you are forced to decide up-front what the dates when you’ll break your neck will be, and don’t even get to blame it on management.
Somebody trashed me because I speak without first listening or reading, so I have read whatever I have found during the last few days on the topic of agile methods. I’m less interested in books or howto’s than in personal experience of people - this is what counts, IMO. What I found is that there are significantly less agile methods advocates than people who consider agile methods rightout dangerous. There must be a reason for that.
There are, however, may people who consider many of the individual techniques employed by agile methods to be useful. Which brings me back to start: agile methods are just hype. Iterative and incremental development was there before agile methods. Classical project management has integrated change management already for a long time. Starting from there, anybody should look for setting up its own processes, rather than buy into methodologies which, at least from what I could observe, work only for a small percentage of the industry.
Another thing that struck me is anecdotical. I was advised to have a look at what big agile methods evanghelists have to say. So just about the first thing I did was to go for Kent Beck’s wikipedia page. Funny things are two: the only achievment listed there is a failed project, and as I write Kent Beck focusses on design of software (states his homepage at the three rivers institute). Up-front software design isn’t written big in agile development. Is it just me spotting something that doesn’t match here?