Short, shorter, single piece flow

A lot of agile practitioners promote the idea of working with short iterations (one or two weeks), so do I.

The faster we can get feedback, the better. If it takes 4 weeks to get all your stakeholders together to look at your application, your adaptability is very slow. On the other hand, if you can show your solution to your stakeholders every week, you adaptability is 4 times faster.

One argument against short iterations often comes from management:

We will lose productivity due to more overhead of planning sessions, demos and retrospectives.

Reality shows that this is not the case. All these meetings will just take less time because of the smaller batch of features.

When you think in lean terms, you realize that we’re working in batch and queue mode here. The team takes a pile of work, completes them all and takes a next pile of work.

What has TPS learned us? That it is better to strive for a single piece flow. Reduce inventories and build quality checks in at every step.

By working in smaller iterations, we get closer to this one piece flow, but there’s still a long way to go. We still have an inventory of finished features that get released to the customer at the end of the iteration. Even if in the meanwhile, they don’t want them anymore (or want them differently).

An alternative is to cancel the iterative mode, and introduce a pull system. Where the team takes a feature from a prioritized list, builds and tests it, and releases it to the customer. Inventory is reduced to zero. Risk of working on out-of-date features is reduced significantly. Adaptability is very high because there’s only one feature in progress. We can re-prioritize our remaining list at any time.

How can you apply this in practice?

  • By introducing WIP limits onto your task board columns
  • By applying a Just-In-Time planning. Only detail out features on top of the TODO list.

Other practices like daily stand-ups and retrospectives are still relevant. So are demos, just pick a regular cadence, or a logical sequence based on the upcoming features.

I really like working like this, it feels very natural. If you can truly get to a one piece flow, things will start to go fast. Features really get to a done state (which in IT is often an exception).

How do I know whether to use short iterations or single piece flow? Well actually, it depends on the situation (what did you expect?). If we’re building a new application from scratch, I tend to propose short iterations. If we’re developing new features to an existing live application, I tend to propose single piece flow.

I’ll explain the benefits of both in a next blog post.

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.

One comment

  1. Pingback: 2 ideal cases for continuous flow « Nick Oostvogels’s Weblog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: