I will not stretch the analogy of jugglers juggling and engineering teams engineering too far. In brief, software and system engineering teams can benefit from working on a few things simultaneously but too many or too few can cause everything to fall apart.
Is this about prioritization?
No. Prioritization of work for software and engineering teams is the act of determining what work is the most important to the business and system.
This is about what comes after prioritization and when the team starts executing on prioritized work. Given our above illustration, does the team focus on the priority one item alone or does it take on additional work?
Well, it depends
Is the team skilled at juggling? Does the team have multiple hands (more than two people)? Are the work items bowling balls, handkerchiefs, or tenpins? As far as the analogy goes this is a question of how many things the team can work on simultaneously without dropping needed quality or execution pace.
Last reference to juggling, the things being juggled are work areas. Okay, enough with it. The point is that even with a Kanban or Scrum type of process it makes sense to bucket an engineering team’s work into areas.
In a team of 7-12 engineers, it is counterproductive to setup work in a way that results in the entire team working on the same features or components simultaneously or for all 7-12 engineers to be working alone. I have seen the former happen most often on established teams taking on new projects building services or features. The team’s product management prioritizes the new work, the entire team piles into it, and then the team’s output slows down because of duplicated effort as the team ramps up.
Individuals on the team go through a learning process before being able to finish new to them work. Throwing an entire team into this state hurts overall forward progress. This may make sense if the team has nothing else to do. If the team is established with existing responsibilities then it probably makes more sense to consciously keep multiple, separate, priorities going at the same time. Allowing a few folks to work on the new items and build context that can be shared with others is generally faster than trying to subdivide sometimes vague and undividable initial research and prototyping work.
A happy middle
The other end of the spectrum where the team is on a number of work areas equal to or greater than the number of team members also has poor results.
No person on this hypothetical four-person team can ask for help from another person without causing a context switch. Each time a context switch happens progress is lost and, worse, the person asked for help must go through a miniature version of the learning steps above to help. What we want instead for established team is something like,
Where items 1 and 2 are small enough for individuals and item 3 ends up being subdivided. Is this always possible? Of course not, but it does make a for good goal that prioritizes the team’s efficiency and ability to help each; something that is perhaps more important that progress on any single work item.