In these last few posts I’ve been trying to edge towards a deeper undestanding of what agile coaches do. These are thought experiments. My aim is to be able to give our clients a means to assess when and whether they are deriving value from the use of our services. And I believe that this will also give us greater means to implement successful improvements in the effectiveness of the software teams we meet.
Several times, both very recently and in the dim past, I’ve seen folks advocate running software process improvement exercises as if they were agile projects. What would that be like in practice? I imagine we would identify process changes we wish to make, creating a story card for each. There’d be a daily stand-up meeting, at which the change team discusses progress, obstacles and plans. There’d be iteration reviews and planning games, and a backlog of change stories, and the change team would chart the project’s velocity, presumably in some kind of “change points”.
What would that change project’s backlog look like? Well if we’re in the business of implementing change to a recipe, I guess it might have a series of stories, each of which puts in place a specific brick of the whole edifice. Sounds like we know where we’re heading already. We’re in danger of turning the software team into a local optimum within the organisation as a whole. We may even shift the bottleneck away from development altogether. Then what?
But if we’re in the business of improving effectiveness there will be no backlog. There can be no backlog. Each change (possibly a small suite of changes) will have been worked out as a response to the overall organisation’s current greatest need. By asking “where’s the bottleneck?”, “where’s the current constraint on throughput?”, “what is the common root cause of our major incidents?”
And after we’ve implemented this change, what next? We must measure, observe, inspect. We must let it settle in and then measure our new levels of throughput and expense. Then ask the questions again – looking for where the bottleneck has moved to now. This is hansei-kaizen, an endless cycle of inspect-adapt-inspect-adapt, as Scrum puts it. And at each cycle it is the overall organisation’s Goal pulling each change through the system.
Now, what about the individual change “stories”, what will they look like? Will each have acceptance tests? Can we assign each a monetary value? Questions for another day…