I’m drilling pretty deeply into Lean these days. Scott Bellware turned me on to some of the more primary sources about lean manufacturing (Ben Scheirman does a good job of summarizing these books based on a recent conversation at ALT.NET). Since then we’ve had a bit of an “asynchronous book club” conversation in voice chat forms.
One of the ideas that’s starting to crystallize is that we’re not treating iterations appropriately. There’s too much emphasis on “weekly” or “bi-weekly” work cycles. In DDD terms we’re treating iterations as an entity when, in reality, iterations or sprints are better modeled as value objects.
Ok, here’s a story for you:
As a product owner, I want to see the team’s velocity over any arbitrary time range, so that I can see how many features a team can deliver in the future.
As a product owner, I want to compare the velocity of any two time ranges, so that I can determine if our velocity is increasing because it should.
So why just the same time range every week? It’s a bitch to have to content with time off and federal holidays. And, sure, I know you can’t treat any individual iteration’s velocity as reliable as velocity is more a trendline over a number of successive iterations, but it seems arbitrary to me that we’d lock the iteration down. We’re back to a batch and queue mentality and the batches only get bigger when we move up to the release level.
Lean would have us pursue the concept of “flow.” That is, we want a single part or component (analog in software: feature/story) to flow through the system continuously. The customer pulls this feature via priority, developers pull the feature via backlog, testers pull the feature via “development complete,” etc. Right now customers can only truly pull at the release level. Now it’s true that you can modify a release but keep a known schedule with a reliable average velocity and a fixed set of points (swap out stories that are stale, etc.), but this seems more than a little anathemas to the competitive advantages purported by a lean approach: chiefly a competitive advantage in demand satisfaction.
I’d love for us to pursue the concept of “feature = release.” Truth is we’re a bit far off from this vision. A number of issues quickly crop up:
- How can customers cope with regular (say weekly) releases?
- How do we structure our teams in this world view?
- How do we get around the need to deliver a minimal set of functionality?
- How does this work with “the big rewrite” as there’s just a ton of features that need to be done for acceptable parity?
As far as #3 and #4 go, I think we need to challenge the scope of projects. When working in a rewrite or brownfield scenario, maybe we should get creative about introducing an anti-corruption layer and pinching off areas of improvement as services rather than waiting for the whole thing to be finished. We can also, in a rewrite situation, create an acceptance environment where the customer team can use the application. This is exactly what we’re doing at Xclaim (where we’re doing “the big rewrite” slowly) and it takes some upfront thought (more on that later), but the approach certainly works.
When we start thinking of features as releases we might need to dig a little deeper and find a solution that marries the desire to release early and often with the realities of a tidal wave of new software delivered regularly. I’m keeping an eye on things like SOA and Composite Applications and OSGi as a means of hitting this goal in enterprise software. I think it goes quite a bit deeper, though. For example, how are users going to cope with new menu items / screens / options / etc. on a regular basis.
First you’ll need an environment, an assembly line, that permits fast introduction of new features. This assembly line will need to allow customers to “mix-and-match” the features delivered so they can determine when and how to release. The user experience will also need strong consideration. We’ll need to find UI metaphors that lend themselves to consistency and discoverability. The bar for this is much, much higher than a product with, say, quarterly releases.
Like anything in Lean or Agile it’ll take a village and a whole lot of cohesive thoughts. I’ll have more to say on this subject as this idea of “flow” is leading me down the path of segmenting product design from feature delivery. This is a slippery slope with pitfalls of BDUF accusation waiting around every corner, so I’ll appreciate a little patience as I experiment and theorize about these ideas.
Is anyone out there truly doing single part flow on their project? Anyone doing release-per-feature or even release-per-iteration? How long are your average releases?