More Than Skim Milk Agile

I’m writing a little about my experiences at Philly ETE 2013. This is a great conference where people can get a little taste of everything development related.

The Path to Agility - Ken Schwaber

The goal of this talk is to get us on the path to agility. I’m here because I’m interested in getting my team more agile. We’re “skim milk” agile right now. I came to this talk believing our agility is a subjectively measured goal. Ken has a different take.

First, a little background on Agile. XP started becoming dominant in 1998, Agile Manifesto 2001. Scrum has been around 25 years! And an endorsement for XP: “If you’re not using XP you have to come up with something like XP.” Ken is happy with the state of Agile and is concerned about its future. In short, it can’t become a passing craze.

One definition of Agile is “to take control of opportunities and respond to challenges while controlling risk.” I wonder how much we pay attention to our risk? What are the risks we face, and how do ideas like introducing Scala impact that factor?

One observation, from Harvard Business Review, is that changing an organization to follow Agile has about a 30% success rate and can take up to 7 years. Ken says that he’s observed companies get to a highly successful Agile state in two or three years and has subsequently seen them revert back to old practices. Why does this happen?

This talk is making me wonder just how agile my team is. In what areas can we be better? We’re going to start addressing planning and info radiators soon. Is this the best place to start? I’m not sure. I think the most important thing, right now, is to start somewhere.

We’re now talking about TDD, BDD, tech debt. OK, but when are we getting to the Path? Ken’s suggestion is to measure your agility using any or all of these.

  • total defects
  • time to get a small change to a customer
  • stabilization time for releases
  • frequency of releases

These are just a few that he mentioned, the most relevant for my team (and for my role, as I don’t have access to the budget). I’d like to know how to measure these. Total defects is easy. I’m happy to say that’s not a high number but it could always be improved. “Small change” is a slippery term, and it will vary from code base to code base.

But we release every week on a schedule and the time to stabilize a release is measured in minutes, not months. So we’re good, right? Not so much. There’s much more to be done and improved upon. We’re “skim milk” Agile, and I’m left wanting. Although this talk did not convince me of a definite path forward, it has impressed upon me the need to measure something and improve an objective metric.