Many benefits are touted for those who chose to adopt an agile approach to software development. Some are more typically cited by coaches and tool vendors as a kind of sales tactic:
- your teams will become more productive
- you’ll ship business value sooner
- customers will be happier
- you won’t build features that aren’t needed
Others, perhaps less vigorously or frequently stated include:
- development proceeds at a sustainable pace, not burning out your staff
- quality typically improves, particularly if one adopts a lot of the supporting technical practices advocated by XP
- for most people, it’s a more fun, interactive and collaborative way of working leading to higher job satisfaction
- the time needed for feature development becomes more predictable
There are more than these but for the purposes of this blog post these will suffice. The question I want to ask (and answer) is, when adopting agile, where should the emphasis be? What benefits should we champion and pursue?
From the perspective of managers and company executives, those items in the first list really resonate. This is understandable; they correspond with responsibilities that those people have. But how exciting are they for those people actually on the teams that have to do the real work of creating working software?
Well, I would argue probably not very exciting at all. I think it’s a misconception, but the “your teams will become more productive” and “you’ll ship sooner” benefits are often interpreted by teams first encountering agile as “you want me to work even harder!?”
This reaction can be compounded with the introduction of daily stand-up meetings. “Oh, so now you want to micromanage it and check in on my progress every day?”
Both of these interpretations are (thankfully) incorrect. This is not the motivation for agile done properly and not what should be going on. It’s easy to see though how this misconception could arise when so much emphasis and commentary exists about those two benefits and how often they get trotted out.
This is why I would argue that the sensible approach is to focus on the benefits in the second list above. Emphasizing changes that bring these benefits are much more appealing to those people actually doing the work. They’re a much more humane and rewarding set of ideas. In my opinion, and experience from the last year, agile done right will really focus on the teams. On empowering them to control much more of the work and how it gets done.
I know that I, as a team member, would feel much better knowing that sustainable, predictable development was valued. I’d feel much better that the increased transparency of Scrum would serve to highlight impediments to my work, that would get the attention they deserve and promptly remedied. I’d love knowing that the organization valued quality and craftsmanship in software development. I’d enjoy not having to estimate every last detail in fractions of hours. I’d almost weep with joy at not having to comb through hundred page specifications of poorly written and ambiguous requirements documents.
Best of all though, focusing on these things, and aiming to unlock that second list of benefits will, I firmly believe, lead to those benefits in the first list. It’s inevitable.