To those who say, “We have tried Agile, and it just didn’t work”
I would reply, “Well, the first time I rode a bicycle it hurt pretty bad, and it wasn’t fun.”
Agile is easily done wrong. I have just started a new job, and the biggest reason the company hired me was to help implement Agile principles. They have been having troubles with their pilot Scrum/XP project. I have now become an expensive pair of training wheels.
Since coming onto the project I have seen several things that were not done right, and because of all this, the project is behind schedule, estimates are completely unreliable, and morale is low. The project that was chosen for this pilot is the most high-profile project in the company (probably not the wisest choice for a pilot), so everyone is looking at Agile with great skepticism now…it simply hasn’t lived up to their expectations.
I think this scenario is more common than we realize, and I can see how many people, inexperienced in the principles, can easily stray off course. Agile is not a magic formula that just solves all your problems for you. It is a disciplined set of principles that you must tweak and follow consistently, or the reward will never be seen. Its a drastic departure from the norm…and its not easy to get it right the first time.
I don’t blame any single person on the team for the failure of the project thus far. Its really an accumulation of many factors:
Under pressure to meet time constraints, many of the practices that seemed less important were forsaken to help make up time. This was done simply out of mere ignorance (not stupidity…there is a difference). When a team has not experienced the benefits of clean, fully tested code, it is highly unlikely that they will place a high value on it knowing they can crank out mediocre code faster. They simply don’t realize they will pay for it later.
Without an understanding of what qualities make up a good user story, they estimated using very large stories with very little detail. This led to grossly inaccurate estimates…and thus, a slipping schedule that only added to the pressure and caused them to revert to their old ways, compounding the problem.
To make matters worse, they never tracked the time they spent on any of the tasks so they could see what was underestimated and why, so they never realized what the problem was or where all their time was going. Because there were no metrics, they calculated their velocity by adding up the working hours available for each employee during the sprint. Obviously, these hours were not all productive working hours, and furthermore, this calculation is a huge divergence from how velocity is used and calculated.
All these factors fed upon one another to bring the project quickly into the red. Thankfully, because they were using Scrum, they knew quickly that things were not going well, and they had time to make course corrections…
I’ll be writing several blog posts in the upcoming weeks on the problems I encountered, their solutions, and other lessons learned in this project. I hope it is of use to others considering implementing Agile principles.
-=CE=-
