Using the Lean Decision Filter: Should I finish what I’m working on or help the team ready new work items?

y1

Once people start to get “Stop Starting Start Finishing” thinking (Kanban) or “focus on the current sprint” thinking (Scrum), a frequent question that comes up is how to deal with people who are required for different activities throughout the work life cycle.

Example Scenarios

The Kanban board shown above illustrates the following scenarios. Users “D1” and “D2” represent the developers, and user “T1” represents the tester.

“I’m a tester who both participates in acceptance test-driven development (ATDD) specification workshop (upstream) and exploratory testing (downstream). The developers are free to start a new story. Should I help them with the ATDD thinking for a new card or focus on finishing the one I’m working on?”

“I’m a developer who both analyzes new stories (you might call it backlog grooming if you’re a Scrum team) and develops them. I see our backlog of ready stories is running low. Should I continue to work on my story or should I move to analyze some new ones?”

Stop Starting Start Finishing

“Stop Starting Start Finishing” talks about finishing things and minimizing the waste of inventory. It seems to say always prefer to finish and not start. Why would we even consider a different approach? And indeed on some rare teams it is reasonable to work in a pure “one piece flow” mode where we focus on one thing, finish it, and then move to the next. But this requires a very high level of collective ownership and collaborative concurrent engineering. This is seldom the starting point and rarely an early achievement of teams trying to set up a more healthy flow of work.

So, in the majority of the teams the challenge is that in order to maintain healthy flow people are typically working on different things. And when the work process of these teams is such that it requires different members of the team to take part in the work in separate areas of the life cycle — so they have to touch the work, leave it, and return to it — we have an issue. Maintaining healthy flow is now in conflict with “Stop Starting Start Finishing” because you would typically always have something to finish, so when are you going to move left on your board or go to work on things related to your next sprint?

Lean Decision Filter

One concept that might help is the “Lean Decision Filter” (see slide 16 from David J Anderson’s  Lean Kanban 2009 Keynote):

  • Value trumps flow: Expedite at the expense of flow to maximize value.
  • Flow trumps waste elimination:  Increase WIP if required to maintain flow, even though it will add waste.
  • Eliminate waste to improve efficiency: Do not pursue economy of scale.

So, based on the filter, what we can deduce is that if we need to start something new in order to maintain flow then this is what we should do — even if it is a potential waste — since we could have focused on finished something.

BTW: In a lot of Scrum teams, this manifests as the heuristic to spend 10% of the team’s capacity on preparing for the next sprint.

A way to decrease the waste of context switching while maintaining flow is to use an ongoing cadence. For example, hold specification workshops or backlog grooming sessions at a regular time each week. This minimizes the impact of the context switch since it provides some heads up for people, instead of surprising them and pressuring them to move to something else. (Otherwise the rest of the team will be idle.)

The Bottom Line

One of the first steps to really getting Kanban or Scrum is to start thinking “Stop Starting Start Finishing.” But the Lean Decision Filter helps us apply the required common sense to real-world situations, where this seems to be in conflict with effective flow — which is actually what we are striving for.

Live Webinar: Flow-driven Product Development

Join Yuval in our upcoming webinar, Flow-driven Product Development: Enterprise Kanban in practice using Leankit. Yuval will discuss how product development organizations are using a lean, flow-driven approach to achieve predictable product releases and enable continuous improvement.

Yuval Yeret

Yuval Yeret is a leading Kanban practitioner in the world of enterprise product development and the CTO of AgileSparks, a world leader in Agile support and training services. He is also author of Holy Land Kanban, a long-time Kanban blogger and a recipient of the Kanban community Brickell Key Award.

5 thoughts on “Using the Lean Decision Filter: Should I finish what I’m working on or help the team ready new work items?

  1. Hi,

    interesting post evenI am struggling with the understanding.
    Could you give more real world examples?

    Do I understand it proper?
    1. Value trumps flow: Expedite at the expense of flow to maximize value.
    – Meaning expedite or fastlane issues will be started even they increase to board wip limit.
    2. Flow trumps waste elimination: Increase WIP if required to maintain flow, even though it will add waste.
    – When WIP Limit is hit pull additional work even if wip limit is “broken”. Do not start …..
    3. Eliminate waste to improve efficiency: Do not pursue economy of scale.
    – Meaning?

    thx
    Alex

  2. Alex,

    1. Value trumps Flow – Yes, that’s exactly what I mean. Another example might be to load more people than efficient on an expedited item to ensure on time/ASAP delivery, even though it is not a very flow-efficient approach. Or allowing pausing an item that is in WIP to enable expediting high-value items, even though that offends the “don’t touch the WIP” flow-optimizing policy.

    2. Flow trumps waste elimination – Here I believe the right approach is to define the WIP limits in a way that gives some leeway rather than being so optimized that there will not be any “rope” in the system. But once the “rope” is tight (reached the WIP limit) I believe the typical approach SHOULDN’T be to override the WIP. The team should discuss what to do in this case, with preference at this point being to optimize the system somehow rather than to just start something to maintain flow.

    3. Eliminate Waste – The easiest example of waste due to high WIP is the costs of delay. Delayed feedback. Delayed time to market. Delayed integration/testing which leads to exponential increases in cost of running these activities to completion. On paper, these big batch activities are more efficient. But since lots of surprises are discovered when running big batches, lots of cycles and effort are required to converge, leading the a lot of waste due to building things the wrong way. Running with smaller batches and faster feedback/delivery eliminates a lot of that waste. Getting to market feedback faster and learning early whether it is worth continuing investment in a feature (think Lean Startup/MVPs/Build-Measure-Learn cycles) can reduce a lot of the waste of building the wrong things. Reducing the WIP and moving from big batch waterfall style processes to smaller batch more iterative processes addresses these kinds of waste. But because of “flow trumps waste elimination” you want to be careful not to be dogmatic here and find the right balance of batch size and WIP that allows you to have enough “rope” in the system and the right economic tradeoff between Cost of Delay and Transaction Costs/Overheads.

    If you’re interested to dive deeper, look at Principles of Product Development Flow by Reinertsen.

    Hope this helps.

  3. Thanks for the reply still struggling with 2. because your explanation “The team should discuss what to do in this case, with preference at this point being to optimize the system somehow rather than to just start something to maintain flow.” sounds like waste elimination is preferred compared to maintain flow.
    Number 1 and 3 are pretty clear now..

    I will check again the Reinertsen book which I tried reading two years ago without getting hooked on it.

  4. Hi Alex,

    The trick is to find a WIP level (and therefore limit) that is at the right balance between maintaining flow and eliminating enough waste. This is a U-curve optimization problem. If you’ll read Reinertsen you’ll find a good coverage of this issue. Zsolt Fabok also provides a good explanation inspired by Reinertsen here. Point is that you should invest in finding the right WIP level — probably through a mix of thinking and experimenting until you find your Goldilocks level (not too wasteful, not too strict, just right).

    In this experimentation and optimization phase you will encounter situations where you run against the current WIP limit and have to decide what to do. The main value of the filter is so that the team knows they need to make a tough decision based on the context. Not necessarily prefer waste eliminator and not always maintain flow. AND if they do allow more work into the system to maintain flow they should mark that as a WIP exception event and discuss what changes to the work system are required in order to avoid such a WIP exception event in the future. And if this exception becomes regular and they decide the right decision is to change the explicit WIP limit policy, that’s probably what they should do after discussing it through, preferably with someone who can challenge them to keep in mind various options and implications around waste/flow/etc.

    I hope this helps. It is hard to do this in theory.

    Cheers,
    Yuval


Leave a Reply