While success stories are all very well, in the agile community we know that we learn more from our mistakes and challenges than from our successes. Hence, I thought it might be more useful for my readers to hear some of my frustrations from my first year leading the software engineering team at Corbis than simply to read my self-congratulations from last week.
I blogged before that I took a different approach on joining Corbis. I went after the culture rather than leading change to a specific prescriptive method, such as Feature Driven Development. I did this because I wanted to achieve organization level change and institutionalization of the results. Previously, I had enjoyed localized success with my immediate development team or project but had not managed an enterprise level adoption, nor had the changed survived my departure by more than a year - at both Sprint PCS and Motorola. As I also stated I was afraid of the J-curve effect that driving home a specific prescribed process change might have at Corbis. So I opted for the long game of cultural change.
While I'm delighted with the results and the cultural change, while hard to measure objectively, appears to be widely recognized anecdotally, I am frustrated by some of the results. I've seen a lot of code released and a lot of successful releases. I've seen some very high quality and very few defects escaping in to our production environments, but I haven't yet seen hyper-productivity.
Jeff Sutherland has been talking a lot about how difficult it is to achieve hyper-productivity. He talks about how few Scrum teams have ever achieved it. [He defines this as performance at least four times higher than might be normal.] He holds up the team that created Borland Quattro Pro as one of the highest performing teams of all time. A team that produced at least a 10x productivity gain. At Agile 2007, I spent some time with Jeff and shared with him the data from the Device Management project that Daniel Vacanti and I led at Motorola in 2004. The data compares favorably with the Borland Quattro Pro project. Even data from lesser performing FDD projects (the Singapore project - though it was a much larger project) and others from my team at Sprint and some others from FDD teams I've met along the way, tends to indicate hyper-productive results, and often with incredibly high quality data. Hence, over the years I've been used to achieving hyper-productivity with my teams.
So what's up at 710 2nd Ave in Seattle? Why no hyper-productivity?
My guess on this is that cultural change and institutionalization and what goes with it - a high degree of autonomy, delegation, empowerment and self-organization - takes a lot longer to achieve hyper-productive results. The advantage is that change is achieved with a much lower degree of resistance, with very low attrition and change-driven churn and the change will stick and survive management changes and the general churn of projects and personnel over the coming years.
In the past, I've been an aggressive change agent. The CMO at Sprint PCS described me as "hard driving." That approach achieved some localized results but equally it made me unpopular with some and probably left a residue of resentment towards management led change amongst the skeptical individual contributors. Folks acquiesced and played along with the rules of FDD and they enjoyed the success of projects delivered, but when the management wasn't there to enforce the rules any more, they fell back in to the same old ways of working. The right way is to let the team make change its own. Through ownership the seeds of long term support and advocacy are born.
So while I wait for hyper-productivity to emerge or evolve through a series of kaizen events, I'm not unhappy. I set out to change a culture and to achieve an institutionalization of those changes that will eventually survive me and the rest of the management team. I've delivered on that goal, but darn it I miss the kick out of seeing some hyper-productivity. Technorati tag: Agile, Software+Engineering, David+Anderson,
