Do you Divide and Conquer or Swarm?
Imagine you have 6 developers and 6 features to build, estimated at 1 month each. Leadership says they are all top priority. Traditional managers would optimize on individual efficiency and assign each developer 1 feature to focus with minimal interruptions.
Here is the problem: Something is going to change.
What if half way through the month a new higher priority feature is assigned to the team? Do you take someone off of their feature and absorb a switching cost? What happens when the developer goes back to their original feature weeks later? Do you double the load of your best developer and ask them to be a hero?
Or what if Feature 3 turns out to be twice as big? If all of these features are on the same code base, then all of the features may be delayed waiting for the long straw.
What if instead of starting all 6 features at the same time we just started working on 2? What would be the impact to change now?
If halfway through we learn of a new priority, we still have the option of delaying the whole thing but we also have the option of deprioritizing one of the original features without much switching cost.By swarming the team on a few problems and working collaboratively (instead of in silos), not only do we get the benefit of less Work in Progress allowing more agility to absorb changes, but we also benefit from increased knowledge transfer.
Swarming and collaborating are new skills agile teams must learn in order to be highly effective with Scrum or Kanban. Don’t focus on trying to optimize the efficiency of one individual’s output, but instead focus on optimizing to achieve great outcomes.
Leave a Reply