In the world of software, it’s always interesting to me to find out how closely the real world matches the text books. Many of the people I speak with are authors, educators or vendors and their point of view can often be quite idealistic. But does agile really work the way it’s described in the classroom?
Chris York, a 10-year testing veteran and four-year software developer before that, has his doubts. “I haven’t seen agile work like it’s supposed to; and after working with it for 18 months, I’m wondering if it does really work.” York knows that it’s been successful for others. We chatted in a Denver coffee shop trying to figure out why the agile project he worked on had such trouble. “We never got close to getting everything done in an iteration. There was no plan for what to do when something went wrong. There was no time allocated for fixing defects.”
York gives me more details of the first software project he worked on that was adopting an agile methodology. The team was co-located with about 20 team members, six of them testers. Other than a one-day training, the team members were not experienced in Scrum, except for the ScrumMaster who was brought into the company to lead the project.
York felt that, although the ScrumMaster knew the lingo, he wasn’t effective in leading the team. “I felt like I was in Kindergarten,” York said, explaining that there were one dollar penalties for all kinds of trivial transgressions including such things as being even two seconds late for a meeting, talking out of turn, having a cup of coffee, a cell-phone ringing, sitting during a stand-up meeting or deviating at all from the stand-up script. He said that team members were encouraged to express disapproval if someone didn’t meet their commitments from the day before too often. “It was also encouraged to try and find a way to get someone else to meet your own commitments for you. This happened on one occasion and it was applauded. Then the person who did the other work was chastised a bit for not meeting his own commitments. It just seemed very inappropriate.”
York describes a project that used a methodology that he helped create: a traditional-agile hybrid -and it worked quite well. “The company had a bad reputation with its clients and something had to change. Releases would take an entire weekend working around the clock. And even after that the product would be two to four weeks getting the bugs that the clients found worked out. We developed this iterative way creating a long term project (four to six months). Each iteration would be four or five weeks and it was highly planned out. After a couple of years of tweaking it, our reputation was good, the releases were smooth (only taking four or five hours) and very few bugs were found by the clients. We didn’t know we had created an agile-like development strategy. We just kept working at it until we found something that worked. The best thing we did was to write complete detailed requirements and then to spend time planning everything, even allowing time to fix the defects and retest them.”
York points out that he knows that agile can work, with the right project and with an experienced team. In this video he compares transitioning to Scrum to a developer making a switch from C to C++. Object oriented programming is a completely different mindset. If we aren’t used to it, we’ll fall back into our old structured programming habits. Similarly, those that find themselves thrown suddenly into an agile environment, may have trouble getting the full value of the methodology.
The lesson learned here seems to be the importance of flexibilty. Agile is not meant to be prescriptive, but adaptive. Each project, team and organization is unique. There doesn’t seem to be one right answer for a universal “best” methodology, but one thing seems to be clear: It’s important to consider the needs of the project and not try and force rules that don’t make sense because they are “agile.” That, in fact, would NOT be agile.