You Don’t “Do Agile”

February 28, 2012

Sometimes we get into right things for the wrong reasons. Like Agile development. I bet there is more than one organization out there that adopted Agile development expecting certain benefits, like delivering software faster, and with fewer defects; or having more engaged – and productive – employees through the use of autonomous teams.

It’s not that these benefits aren’t possible – they are. But they aren’t what it means to be agile. A framework like Scrum or practices such as Test-Driven Development and pair programming can be classified as just that, agile practices, but the practices themselves aren’t agile. It is more accurate to state that they support agility…

Or not. I’ve heard of Scrum implementations that are really a series of mini-waterfall projects. Others are using what at best could be considered command-and-control Scrum – the teams are far from autonomous because everything from sprint lengths to estimates are being dictated to the teams. This is far from being agile.

Test-Driven Development and pair programming enable us to approach the work in a very different way and improve our execution. But using the tools alone will only provide an incremental improvement; the quantum improvement comes from being truly agile. And being agile is in the understanding of a different way of approaching work along with the mindset and behavioral changes that come with it.

Being agile is an organizational concern, not just something the “development teams do.” An agile organization is one of continuous improvement of the people and the system. There is a distinct shift away from managing of specialized functions with a focus on high utilization rates of “resources” (people) to optimizing the whole.

Lean and agile organizations routinely concentrate on its workflows, identifying where queues and bottlenecks exist and taking the time to determine how to eliminate them and execute better. They don’t conduct months of study on this, either. A change is quickly assessed and if deemed worthy of trying, the change is implemented and inspected in a short cycle using Toyota’s Plan-Do-Check-Adapt (PDCA) cycle:
  1. Plan. Define what you expect to do and to happen. This is the hypothesis or prediction.
  2. Do (try out). Test the hypothesis, that is, try to run the process according to plan. Observe closely.
  3. Check (study). Compare the actual outcome with the expected outcome.
  4. Act (What’s next?). Standardize and stabilize what works, or begin the PDCA cycle again.
Agility isn’t a benefit, nor is it a practice or set of practices. It is a quality of the organization. An organization and its people need to be adaptive, responsive, continually learning and evolving. And by being adaptive and responsive, think beyond contending with changing software requirements. It means improving the organization at a faster rate.

Leaders in an agile organization have a vital role in all of this. Don’t concentrate on the anticipated benefits and manage towards them – the benefits will come if organizational change takes hold. Look deeper, beyond the practices. Mike Rother, in his book, Toyota Kata, summed this up nicely:

“The primary task of Toyota’s managers and leaders does not revolve around improvement per se, but around increasing the improvement capability of people.”