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…
This is the approach in my organisation and I would not recommend it. It is a example of Miasma Theory; the team fails to tackle the locus of the problem and instead moves to managing the effects of the problem. I favour maintaining pressure on flow. Get the team to focus on the queues and to accept the idea they’ll need become multi-disciplined if flow is to be maintained. Introduce stimuli to get the team familiar with helpful practices like BDD, ATDD, TDD and show them how such practices applied early can demonstrably increased flow later in the cycle.
Can you please elaborate on how a team that is already using ATDD specification workshops to READY the story (in which the testers, developers, customer representative/product owner/etc. participate), where developers already do a lot of the automation, and in which the team does want the testers to do some testing after acceptance tests are run (e.g. exploratory tests) would actually behave according to your guidelines? Are you saying just go to “One piece flow” everyone focusing on a story until it is done and only then moving on to the next story?
As I said, there are teams where this is possible. For others, suggesting that as the only guidance may be too extreme, for sure as a starting point. Teams need better guidance on how to get there. Same like people don’t start running a marathon one morning. They start by running 15 minutes.
And my view is we need to carefully balance the fitness improving regime that teams use and the goal they are focused on.
I agree one piece flow is a nice goal to focus on. I find most teams need stepping stones in order to get there. I fully agree while they use those stepping stones they shouldn’t forget what they are aspiring to and stay stuck.
Thanks again for reading and commenting!
For a high functioning team who are genuinely doing BDD/TDD (I’ve yet in my 20 year career to encounter a team that couldn’t make considerable improvements in this area, but I digress) then I would suggest initially at least pairing them with a tester to work on the exploratory testing.
Continuous improvement should not be confused with improvement theatre. To reiterate, the pattern of behaviour I most often see if the organisation succumbs to this approach is teams moving to tackle the downstream symptoms but not the upstream cause.
[…] wrote a thoughtful post today about team liquidity. In this post, in passing, he mentions the Lean Decision […]