Once people start to get “Stop Starting Start Finishing” thinking (Kanban) or the “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.
Some example scenarios:
“I’m a tester who both participates in ATDD spec. 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 talks about finishing things and minimizing the waste of inventory. It seems to say always prefer to finish and not starting. 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?
One concept that might help is the “Lean Decision Filter” (see slide 16 from David J Anderson’s Lean Kanban 2009 Keynote):
Lean Decision Filter
• 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…).
Bottom line – one of the first steps to really getting Kanban/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.
Do you see this problem in other forms? Did you find other ways to rationalize the right thing to do? Do you have other tips/suggestions to people facing this problem? That’s what the comments are for…