Interviewer:
What is the best way to utilize a small team with oversight of multiple products?
Mr. Agile®:
This is a very common challenge. The main thing that we’re looking for in that situation is how do we limit our thrashing. When we talk about effectiveness, we know that as a person you will lose as a minimum–not a maximum–of 30% just in the cognitive demobilization and remobilization associated with task switching. So, we want to be able to maintain focus as long as possible.
The best-case scenario is teams start on a project and see it all the way through to the end. This is how we will be the absolute most efficient.
Worse than that is you have a team that is focused for a release. So we’re working on project A, and we work on that until we can release something of value to the customer. Then we thrash to project B, and deliver something that we can give to the customers. Then we thrash to project C.
Worse than that is that the team is stable at the sprint level. So we run a sprint and we produce something that is potentially shippable–that is demonstrable–then thrash over to project B and produce something that is potentially shippable.
Worse than that is that the team is stable at the day level. So Mondays we work on project A, and whatever we get done is what we get done. Tuesday is for project B, and whatever we get then is what’s going to get done.
Worse than that is the team is stable at the hour level, which means mornings are for project A, afternoons are for project B and we’ve got this structural thrash that happens over the lunch hour.
What is [unfortunately] the most common scenario, though, is that teams are stable at the minute level. We get started on project A, somebody starts screaming about project C, we drop what we’re doing with project A and thrash over to project C. This is really what we’re trying to avoid.
As long as I can have stability within the scrum team, whatever that time box is, as long as I can be consistent with it, I can use scrum and I can use it very easily. I can extrapolate because of that consistency. If I can’t have it, what we normally say is let’s try to use Kanban. We’ll take a single item that is for project A, and we’ll at least see that item to completion. Then we can thrash to project see and we’ll see that to completion. Then we can thrash the project F, and at least we have some sort of break point that is at the completion point rather than the midpoint. That’s really what we want to avoid is this midpoint thrashing.
