Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Iterations vs. Flow

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.

or…

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:

  1. How can customers cope with regular (say weekly) releases?
  2. How do we structure our teams in this world view?
  3. How do we get around the need to deliver a minimal set of functionality?
  4. 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? 

 

This entry was posted in Agile, flow, iterations, lean. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

10 Responses to Iterations vs. Flow

  1. Scott says:

    I’m not sure how to explain this in a way that won’t sound stupid. We have a major system in operation that has 3 types of change needs: 1) new feature, 2) bug, 3) new line of business. The feature roadmap is strictly nonlinear. Either the customer decides that there is a need for something “asap” which typically means “next sprint” or they have items on the backlog that are all of equal priority more or less, and are handled as at-time-of-sprint-planning conditions dictate. So basically at sprint planning we either have a high priority “immediate fill” order from a customer, or we have n number of older orders around which to build a sprint.

    It’s too much to really comment here, and it’s an evolving process (today we abolished arbitrary iteration timespans altogether to get even closer to iteration=feature release), but I can put together an email or a blog post or discuss it with you if you like.

  2. Dave Laribee says:

    @Scott

    > release per iteration

    How far does your road map extend? Are you doing what if iterations way in advance? Are you running single-team-per-project?

  3. Scott says:

    Dave,

    I’m doing release per iteration, and iteration tends to be feature or family of related features. Iterations range typically from 1 week minimum (I find this to be pushing the envelope in getting something new spec’d, coded, tested, and deployed, but it works) to 3 weeks maximum. If something is going to take more than 3 weeks it gets spun off into something separate (a “new” project type scenario) or broken down into more granular bits.

    Tomorrow I’m going to be holding a meeting (open space style even) to try to work on a more organic, more flow-ish process.

  4. Dave Laribee says:

    @ET – Velocity should increase over long periods due to continuous improvement / kaizen. As we find ways to work smarter not harder I would expect course estimates of difficulty to remain more-or-less constant while the technical aptitude, domain knowledge, and overall design of the system improves. Now I’m talking a longer period. Let’s say a quarter. If we gain a few points of velocity a quarter, that’s a good sign of kaizen.

    I will post some thoughts on this in the near future. It’s a big topic.

  5. ET says:

    “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.”

    Why should the velocity increase? Over what period?

  6. Dave Laribee says:

    @Bruce – Can I talk to you (over Skype or phone) about your experiences with this? I’m extremely interested. Send me an email if you would, david/at\laribee/dot\com

  7. Bruce Onder says:

    Dave,

    We actually evolved from pushing releases to allowing our stakeholders to pull together releasable features from our assembly line of tested features (small user stories).

    It was like an assembly line where the customer puts raw materials into the hopper and the crazy feature making making spits out product. The products don’t necessarily come out in the same order they went in, though, which was fine because the customer could then pick from a list of things ready to go to production.

  8. Chris Holmes says:

    “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.”

    Bingo.

  9. Dave Laribee says:

    Sure. What doesn’t go so well is changing navigation schemes or the UX of a large feature or information architecture paradigms. That’s what I was trying to get at with “a little design up front” in terms of UX and architecture.

  10. Evan says:

    I would argue that adding single menu items frequently provides a better user experience than putting them out in batches (of a relatively larger size). I’ll couch this in the idea that it allows the user to learn the system incrementally at a fine-grained level.

    Or so my theory goes..

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>