After narrowly surviving my umpteenth project using the Waterfall method it was obvious something had to change. It turned out the major rewrite we'd done wasn't such an ordeal for the coders on the team. What they really disliked boiled down to three things:
- They didn't like being dependent on others for their success.
- They didn't like not knowing what the other team members were working on.
- They didn't like the negative feedback and/or scope creep during each full-scale demo to our customers.
One of our team members had a very positive experience using eXtreme Programming (XP). I had been exposed to XP a few years earlier by taking an informal class with Ward Cunningham and a few of his former students. My key learning at that time was Ward's emphasis on Test Driven Development. Our XP champion loved the paired approach - when you pair up two programmers you get instant code review, a real-time exchange of ideas, and higher productivity.
- The team would no longer have single points of failure, i.e. would have built-in backups.
- The team members would always know what at least one other person was working on.
- The team would focus on finishing small, functional parts of a project and demo them to our customers.
We implemented XP as best we could. We still had our Product Requirements Document (PRD). But instead of writing monolithic High Level Design (HLD), GUI mock-up, and Low Level Design (LLD) documents for the entire project, we'd group PRD items and write a story document. The story would describe how the finished functionality would work (tying back to the PRD) in a way the customer could understand. We'd present the story to the customer, agree on its wording, and then start programming. Then we would demo the finished story.
See the first problem? Based on a set of static requirements, a group of developers tell a customer how the program will work. We did this because our customers were too busy to write the stories with us. If you're going to implement XP, you must have committed customers who are willing to go through the entire planning game with you. You can't be distanced from your customers or have them be so busy that they only provide requirements.
Our second problem was that paired programming didn't work for us. From a productivity standpoint it didn't work at all. Pairing two senior developers led to higher productivity, sure, but any mix of skill below that led to a slowdown. The senior folks would get frustrated with their less-skilled peers, personality and communication conflicts would get in the way, and we still had bugs. Our pairs eventually self-assigned around people who could work with each other, meaning I'd always be worrying about some pair or other. From a project lead perspective it was easier when I could assign individual tasks.
Our last problem was difficulty understanding the culture of XP. We "assumed simplicity" and had no tools supporting our process. We "embraced change" and had folks get bogged down with refactoring before their modules were actually working. We had a bare minimum of documentation, making understanding technical design difficult. It felt like everything was always changing and no one knew what was coming next.
We spent about a year on XP and managed to punch out over a dozen point releases before really wanting something else. We eliminated the backlog that had accrued during our huge rewrite but we weren't doing paired programming anymore. The fact that we were working on 4-8 week projects limited the value of short iterations. And XP still felt very awkward to most of us.
The light at the end of the tunnel appeared. In June, 2008, Steve McConnell, CEO and chief software engineer of Construx Software, gave a presentation called "Making Agile Work for You." In it he noted that his experience showed about 80% of the shops who picked up XP later dropped it, while 80% of the shops that picked up "Scrum" kept it. Whatever "Scrum" was, it sounded like it was worth looking into.
Up Next: From XP to Scrum
Technorati tags: Extreme Programming Agile