Swarming: One-Piece Continuous Flow
... companies, teams, and individuals often fail to get things Done by working on too many things at once and not working together to help one another finish the highest priority Sprint Backlog Items. While it is the Product Owner’s responsibility to order the product backlog to maximize value delivery, it is the responsibility of the ScrumMaster and Development Team to order the implementation of the Sprint Backlog to maximize flow of production. (See pattern on Developer-Ordered Work Plan.)
✥ ✥ ✥
Working on too many things at once leads to radical reduction in the effectiveness of an individual, in the velocity of a team, or a company. It can cut velocity by 50% and sometimes reduce it to zero.
This has been observed in Openview Venture Partners portfolio companies  and in the largest and most successful software companies (Microsoft, Google, Adobe, and others).
The personal preferences of a team member and impediments in the work environment often cause scattered effort. A team works on multiple items at once resulting in excessive work in process, low process efficiency and associated delays.
Working on multiple items delays getting backlog items tested. If multiple work items are delayed during a sprint, there may not be enough time to test all of them at the end of the Sprint. Even worse, in Silicon Valley and in Europe, some teams working on complex software find that not identifying and fixing a bug in a Sprint can turn one hour of testing at code complete to 24 hours of testing three weeks later. If all testing is done later, something that could be delivered in a month can take two years to deliver.
Compounding the problem, Jerry Weinberg showed that multitasking introduces significant delays in getting things done .
Even worse, recent brain research shows that multitasking makes you stupid as well as slow, while increasing stress and accelerating ageing .
Working on many things at once gives the illusion that things are going faster and plays on management desire for efficiency of the individual worker. Yet this increases the number of defects that must be fixed and tested later, escalates development costs and slips release dates.
Developers often want to work independently to avoid stepping on each other’s code, a symptom of a dysfunctional team with poor process and engineering practices. At Google it was solved by implementing a daily meeting and swarming to get things Done .
Focus maximum team effort on one item in the Sprint Backlog and get it done as soon as possible. Whoever takes this item is Captain of the team. Everyone must help the Captain if they can and no one can interrupt the Captain. As soon as the Captain is Done, whoever takes responsibility for the next priority backlog item is Captain.
This pattern is about maximizing velocity to deliver business value by getting the team to work together. It requires a mind shift to focus on flow of production by swarming on the backlog items. Individual efficiency does not optimize production while slack can speed things up.
This is a fractal pattern and applies at the enterprise level, portfolio level, team level, and the individual level. See Covey’s work on habits of effective people . It leads to happier teams and cultural success.
✥ ✥ ✥
You can encourage a team to Swarm by keeping the team's identity focused on the team as a whole rather than individuals. Limit or eliminate rewards for outstanding individual accomplishment. Work against a "hero culture" by eliminating overtime, overtime pay, and a work ethic that values working harder. Make sure that you have a Cross-Functional Team to avoid situations where only select team members can work on a given PBI. And motivate the team to do something great every Sprint with a well-articulated Sprint Goal.
Working the highest priority PBI on the Scrum Board will tend to cause individuals and teams to self-organize to maximize flow in a Sprint. Systematic showed how implementing this pattern doubled the productivity of every team in the company . Citrix Online applied this pattern at the enterprise level and reduced release cycles from 42 months to less than 10 months resulting in substantial gains in market share for their products .
Implementing this pattern moves the team toward one-piece continuous flow. Toyota demonstrated that this optimizes production capacity:
The team continuously adjusts its tack in a Developer-Ordered Work Plan. They come together as one mind to modulate this direction every day in the Daily Scrum. However, all direction adjustments happen within the terms of the Sprint Goal, which itself is a rallying point that can help channel the flow of the team. A team that works closely together builds a shared vision of what the product is and is able to grow pride in the product and in their achievement; see Product Pride.
There is an extensive computer science literature on swarming dating back more than 20 years. See, for example, http://pj.freefaculty.org/sdg/biblio/ or patterns community work in Richard Gabriel's keynote at OOPSLA'2002. Members of the Scrum community have also been talking about swarming for many years. See Henrik Kniberg's King/Servant pattern or Dan Rawsthorne's work .
 T. Ohno, Toyota Production System: Beyond Large-Scale Production: Productivity Press, 1988.
 J. K. Liker, The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. New York: McGraw-Hill, 2004.
 J. Sutherland and I. Altman, "Take No Prisoners: How a Venture Capital Group Does Scrum," in Agile 2009, Chicago, 2009.
 G. Weinberg, Quality Software Management: Systems Thinking vol. 1: Dorset House, 1992.
 D. Rowley and M. Lange, "Forming to Performing: the Evolution of an Agile Team," in Agile 2007, Washington, D.C., 2007.
 M. Striebeck, "Ssh! We're Adding a Process . . ." in Agile 2006, Minneapolis, 2006.
 S. Covey, The Seven Habits of Highly Effective People: RosettaBooks, 2009.
 J. Sutherland, C. Jacobson, and K. Johnson, "Scrum and CMMI Level 5: A Magic Potion for Code Warriors!" in Agile 2007, Washington, D.C., 2007.
 D. Greening, "Enterprise Scrum: Scaling Scrum to the Executive Level," HICSS'43, Kauaii, 2010.
 M. Rother, Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results: McGraw Hill, 2010.
 D. Rawsthorne with D. Schimp. Exploring Scrum: The Fundamentals. CreateSpace Independent Publishing Platform; 2nd edition, 2011.
 boundless.com, "Inputs to the Production Schedule," https://www.boundless.com/finance/textbooks/boundless-finance-textbook/forecasting-financial-statements-4/forecasting-the-income-statement-50/inputs-to-the-production-schedule-241-3865/