By Josh Sherwood, AccuRev engineer
I had the opportunity to co-present a talk on Continuous Integration at the Agile 2008 conference this past week. While there I took the opportunity to attend a variety of sessions. Workshops discussing Business Value, Experience reports describing transitions from Waterfall to Agile, Aspects of Leadership in and Agile Environment and many others. And okay, I’ll admit that I have been a skeptic of a variety of the Agile Processes. Our CTO, Damon Poole, has been an Agile advocate for some time now. He and I have had ongoing discussions about the value of Agile practices. We would talk about the iterative model, going back and forth about the value and how to describe it to different groups. We’d eventually come to an understanding, but there were still many elements that I have been skeptical of and found difficult to see their value.
In addition to the elements of Agile practices that Damon and I would discuss, I started taking a look at other Agile topics. I looked at things like estimation, use of 3×5 cards and even pair programming. I didn’t see the value in the sticky note processes, I mean using a paper process to discuss a digital product? I didn’t see the value in pair programming, especially for consulting companies where your development hours translate directly into billable hours.
But then I came to the conference. I listened to people like Richard Sheridan talk about his experience with Pair Programming, why and how it worked for him. I listened to experience reports from companies like Healthwise, and heard about the difficulties they overcame to improve prior processes and move into Agile. And I spoke with Scrum trainers, who were encouraging their customers and helping them overcome the hurdles of understanding, while remaining flexible about sharing Agile ideas.
What was great about things like the Pair Programming was the team participation. Not only was Richard there talking about their factory model, team members were in the audience, talking about what they take away from the model. They talked about some of the things an individual developer would run into. You know those times, where you are working on a particular problem and just can’t quite figure out how to break the bottleneck. You wander around, get some coffee, or browse the web checking the Olympics. With their pair model, now that bottleneck has two developers working on it. No they’re both not checking their email, they are floating ideas back and forth, bringing to bare the problem and coming to some resolution. With a close proximity to other pairs they are also propogating these ideas farther out amongst the group. Yes there is training and not everybody can manage to work in pairs, but by using this model and actively rotating the pairs they ensure there are no knowledge silos. If someone is out one day there is more than one person who can tackle the problem at hand.
It has been a community of ideas this week. Some people use Scrum but don’t perform retrospectives. Some people model agile practices, but don’t follow a specific practice. Some people are taking the team based processes and developing large scale models for larger development tasks.
As I sit here building out the story for some of our future ideas, I’m encouraged that we can adopt more of the Agile practices than we have in the past, work through some of the confusion those ingrained in waterfall have with new processes, and further the practices that have allowed us to deliver innovation at a faster rate than we could with older models.