Swarming: One-Piece Continuous Flow

Waves never stop, and you can ride only one at a time.

“Software development is not a relay sport” — Simon Brown

... 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 can radically reduce individual effectiveness, team velocity, or a enterprise well-being. It can cripple velocity and can sometimes reduce it to zero.

This has been observed in Openview Venture Partners portfolio companies [3] 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.

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. [12]

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 [4].

Even worse, recent brain research shows that multitasking makes you stupid as well as slow, while increasing stress and accelerating ageing [5].

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 [6].


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.

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 System1988, 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 [7]. 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 [8]. 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 [9].

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.” [10]

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 [11].


[1] T. Ohno, Toyota Production System: Beyond Large-Scale Production: Productivity Press, 1988.

[2] J. K. Liker, The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. New York: McGraw-Hill, 2004.

[3] Jeff Sutherland and I. Altman, “Take No Prisoners: How a Venture Capital Group Does Scrum,” in Agile 2009, Chicago, 2009.

[4] G. Weinberg, Quality Software Management: Systems Thinking vol. 1: Dorset House, 1992.

[5] D. Rowley and M. Lange, “Forming to Performing: the Evolution of an Agile Team,” in Agile 2007, Washington, D.C., 2007.

[6] M. Striebeck, “Ssh! We're Adding a Process . . .” in Agile 2006, Minneapolis, 2006.

[7] S. Covey, The Seven Habits of Highly Effective People: RosettaBooks, 2009.

[8] Jeff Sutherland, C. Jacobson, and K. Johnson, “Scrum and CMMI Level 5: A Magic Potion for Code Warriors!” in Agile 2007, Washington, D.C., 2007.

[9] D. Greening, “Enterprise Scrum: Scaling Scrum to the Executive Level,” HICSS'43, Kauaii, 2010.

[10] M. Rother, Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results: McGraw Hill, 2010.

[11] Dan Rawsthorne with Doug Schimp. Exploring Scrum: The Fundamentals. CreateSpace Independent Publishing Platform; 2nd edition, 2011.

[12] 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/.

Picture from: https://wallpaperscraft.com/download/surfing_guy_wave_splashes_crest_extreme_hands_balance_8817/3840x2400.