An Obsession with Agility
I attend the XP/Agile Toronto User Group fairly irregularly these days, but I still consider myself a member and contributor. This week, Dmitri Zimin(e) presented “Agile Enough”, a case study of Opalis Software. In it, he mentioned their early setbacks, among which the biggest obstacle was an “obsession with agility”. When I read this, I thought back to all the projects I’ve worked on since 2000 when I was still at IBM, and I see a common theme. The failures have had, at their root, the obsession with acting agile, being agile, performing the agile practices, appearing to be agile… all this instead of focusing on helping the project succeed. The successes have had, at their root, a lack of this obsession, primarily because in those cases, no-one was opposing the agile practices. So it’s reasonable to wonder why this happens.
My greatest successes have been either solo projects (my last six months at IBM, my work with the Toronto Blue Jays) or projects where everyone agreed to focus on delivering incrementally, quickly, with quality (the first two months at Toyota) and allowed agile practices to be the way we achieved that goal. My greatest failures (the rest of my time at Toyota, my most recent transitions over the past 18 months) have stemmed in part from wasting energy trying to convince people to work one way or from wasting energy on “compensating” (as arrogant as that sounds, that’s what we were doing) for the poor habits other team members seemed to insist on maintaining. It is clear to me now that there wasn’t true buy-in from everyone about how we would work, so that, for example, when schedule pressure kicked in, they would immediately go back to the old ways of working. I know, from my experience and from that of others, that this back-sliding is human nature and part of any change program, but I’m left wondering what to do about it. What can I do differently?
First, I can stop fighting or trying to convince people to work my way, but rather offer them the opportunity to work my way and evaluate that for themselves. If it helps them, then we can work together, and if not, then we can’t. That’s all right: there is no rule that says we must be able to work together to be friends, or even to be civil to one another. Next, I can stop focusing on the practices and instead focus on the results. This means measuring the current results before trying to change things. I’ll admit that I’ve generally done a poor job of that so far. Finally, I can stop ramming change down people’s throats, but instead invite them to take the journey with me. I think I can achieve this through regular retrospectives in which we examine what’s working and what isn’t working, then propose together ways to improve. I need to remember that my solution, although it works for me, isn’t always best for everyone else, including whichever team I’m on. I think if I apply these three ideas to my consulting work, I’ll find better results. This means learning what to measure, how to measure it, and how to present that information in non-threatening ways. I suppose I know my next area of research… now we’ll just see whether I actually do it.
“I didn’t ask ‘can he do it’, I asked ‘will he do it’. With Eddie, those are two different things.” – Bert Gordon, The Hustler