By Ray Bagley, Director Product Planning and Management
Spatial began adopting the development practices of Agile and XP (eXtreme Programming) almost two years ago. And in the spirit of the Agile tenet to continuously inspect and adapt, we are not “finished” with the adoption… and may never be! About every six months we make significant changes to how we apply Agile methods, based on lessons learned from the prior period. Here are a few tips for the benefit of others making a similar move.
Teams really work
… when you go all the way, that is! A group of people with a common manager, working on a pile of unrelated tasks is not an Agile Team. They will be as effective as individuals can be, and they will collaborate when it is necessary or convenient. But when we put a half-dozen people into a team room, give them a singular product development objective, and removed all their other responsibilities (distractions)… wow! The teams have produced far beyond what they would have produced as individuals over an equivalent time. We saw tremendous benefit of cross-training because we made up temporary teams with individuals from different specialty areas and cross-pollination as people learned little things from each other like debugging methods, environment optimizations, and other productivity gains. Spatial has been using Scrum management of all our teams for more than a year, but never really witnessed a sprint mentality like this until we went all the way: focused objective + empowered team + no distractions = serious results. Like a physical sprint, however, it’s not sustainable indefinitely (our limit seems to be about 4-5 weeks). The team builds to a very high energy peer environment that draws the best out of all the members, but all report that it is exhausting and they need time to recharge between sprints.
Agile as guidelines, not dogma
All the Agile literature I read two years ago seemed to be based on small R&D groups building new applications in relatively simple product domains. We spend a very large portion of our time maintaining, correcting, and refactoring a huge code base (millions of lines) that is, in places, 20 years old and is deployed to hundreds of thousands of end users! We don’t have unit tests in all that code and we can’t afford to create them for every piece of code we touch… but we do add unit tests for new development and for major refactorings. We also find that Scrum is quite effective for an Agile Team as described above, but isn’t very useful for managing defect fixing. We can’t reliably predict the time it will take to root-cause and fix most defects, so scheduling them into an iteration along with project-related stories tends to kill the team’s ability to accurately predict their capacity (we tried time-boxing – it didn’t work). We are moving to a scheme wherein we put Agile Teams onto all the project stories, and handle maintenance and customer-found defect work with individuals or pairs taking tasks/bugs off the top of a prioritized queue.
Product Owner != Product Manager
There is a big trap in the early Agile literature that comes about when you scale Agile into an enterprise with more than a few development teams: what is the “Product Owner”? If, like Spatial, you have a lot more development teams than product managers, then wisely ignore those books and coaches that tell you that every team needs a Product Owner and that person should be the Product Manager. Instead, read the more recent publications (Pragmatic Marketing is a great source) that deal directly with this topic.
In short, Agile is proving to be good for Spatial. It is important to remember that Agile is not one-size-fits-all. Choose a subset of the 10 or so XP practices to implement and do it, but choose carefully because some practices are tightly coupled. Agile adoption is growing rapidly and as it does the literature is maturing to offer lessons and guides to companies which didn’t fit the ideal models documented a few years ago.
