“Software development is not a relay sport” — Simon Brown
... companies, teams, and individuals bring things to Done by working together on them. While it is the Product Owner’s responsibility to order the Product Backlog to maximize value delivery, it is the responsibility of the 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 can radically reduce individual effectiveness, team velocity, or enterprise well-being. It can cripple velocity and can sometimes reduce it to zero. If everyone is working on their own thing individually, they are unlikely to help each other and, in the long term, learn from each other.
The personal preferences of a team member and impediments in the work environment often cause scattered effort. A team working on multiple items at once results in excessive work in process, low process efficiency and associated delays.
Work in process (acronym: WIP) or in-process includes the set at large of unfinished items for products in a production process. These items are not yet completed but either just being fabricated or waiting in a queue for further processing or in a buffer storage. The term is used in production and supply chain management. Optimal production management aims to minimize work in process. Work in process requires storage space, represents bound capital not available for investment and carries an inherent risk of earlier expiration of shelf life of the products. 
Working on multiple Product Backlog Items at once delays getting them 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 aging. 
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 Product 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.
In 1947, we arranged machines in parallel lines or in an L shape and tried having one worker operate three or four machines along the processing route. We encountered strong resistance among the production workers, however, even though there was no increase in work or hours. Our craftsmen did not like the new arrangement that required them to function as multi-skilled operators. They did not like changing from “one operator, one machine” to a system of “one operator, many machines in different processes.” Taiichi Ohno, The Toyota Production System, 1988, Chapter 1.  — Figure from Liker, The Toyota Way, 2004, Chapter 8, Figure 8-4. 
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. Working together as a team on one PBI at a time will broaden team members into new skill sets and result in more multi-skilled individuals. 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:
In its ideal, one-piece flow means that parts move from one value-adding processing step directly to the next value-adding processing step, and then to the customer, without any waiting time or batching between those steps. For many years we called this “continuous flow production.” Toyota now refers to it as “one-by-one production,” perhaps because many manufacturers will point to a moving production line with parts in queue between the value-adding steps and erroneously say, “We have continuous flow, because everything is moving.” Such a misinterpretation is more difficult to make when we use the phrase “one-by-one production.” 
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.
Members of the Scrum community have also been talking about swarming for many years. See, for example, Dan Rawsthorne’s work. 
—. “Inputs to the Production Schedule.” boundless.com, 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/ (accessed 2 November 2017).
 Gerald Weinberg. Quality Software Management: Systems Thinking, vol. 1: New York: Dorset House, 1992.
 Darren Rowley and Manfred Lange. “Forming to Performing: the Evolution of an Agile Team.” In Agile 2007, Washington, D.C., 2007, pp. 408-414.
 Mark Striebeck. “Ssh! We're Adding a Process ...” In Agile 2006, Minneapolis, 2006, pp. 193-201.
 Taichi Ohno. Toyota Production System: Beyond Large-Scale Production. New York: Productivity Press, 1988.
 Jeffrey K. Liker. The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. New York: McGraw-Hill, 2004.
 Steven Covey. The Seven Habits of Highly Effective People. New York: Rosetta Books, 2009.
 Jeff Sutherland, Carsten Ruseng Jakobsen, and Kent Johnson. “Scrum and CMMI Level 5: A Magic Potion for Code Warriors!” In Agile 2007, Washington, D.C., 2007, pp. 272-278.
 Dan Greening. “Enterprise Scrum: Scaling Scrum to the Executive Level.” In HICSS' 43, Kauaii, 2010, pp. 1-10.
 Mike Rother. Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results. New York: McGraw-Hill, 2010.
 Dan Rawsthorne and Doug Schimp. Exploring Scrum: The Fundamentals 2nd edition. N. Charleston, SC: CreateSpace Independent Publishing Platform, 2011.
Picture from: Pixabay (under CC0 license).