Involve the Managers*

...the organization has committed to adopting Scrum and is now starting to use Scrum to guide the conception and realization of its products. But Scrum is considerably different than traditional organizational structures, and questions arise about the place of traditional organizational roles. Those who were comfortable with management roles in traditional product development now seek analogues in the Scrum culture. Management has a particularly visible presence in large organizations that produce multiple products, but also carries influence in traditional organizations of all sizes. Management responsibilities overlap with those of Scrum roles. An imminent dilemma becomes clear as the organization deliberates the extent of management control, or whether there should be management at all.

✥ ✥ ✥

There are no managers in the Scrum framework. Scrum Development Teams are Self-Managing Teams, and the Product Owner, while accountable to stakeholders and investors, isn’t subject to control by any higher power within the enterprise. So managers in an agile transformation have difficulty finding an outlet for their contribution except as an otherwise undifferentiated support role.

A development manager in a traditional organization coordinates work and may actually give work assignments in a Development Team. But the need for responsiveness, and for making rapid decisions close to the work, suggest that developers instead manage their own day-to-day development activities. This is how Scrum product development works. Yet the traditional management skill set and identity may still make sense in a complex product development organization. This skill set falls outside of day-to-day development and outside of what Scrum brings to the organization.

The position of “managerˮ often carries distinguished standing under the law in terms of being able to speak for the company, and in terms of carrying liability for corporate activities. Managers have the station and power to restructure the organization while Product Owners do not. While individual Scrum Teams can navigate daily interruptions and exigencies, they individually cannot adeptly deal with issues beyond the scope of a single team. For example, it is awkward for any single Product Owner to bear the contractual responsibility for a relationship with an external vendor that supplies multiple product developments (i.e., the development efforts of multiple Product Owners).

In the usual English language sense of the term, management is fundamentally about control and responsibility, according to the dictionary definition ([1]). Responsibility means willingness to take accountability. One reason there is no management in Scrum is that control of the development process is decentralized across members of the Self-Managing Team. Because development is complex, development leadership moves dynamically from team member to team member. Efficient work languishes under any locus of centralized control or management. Yet, there are functions other than development per se necessary to sustain a product development effort. The fact that the Product Owner controls (has the final say over) the direction of the product is indeed a form of control, so the sentiment that Scrum is without any loci of control is a myth.

There are yet other facets of operating a production organization that, as with the Product Owner case, may be better suited to centralized decision-making than to collective consensus. For example, some crucial business decisions may owe more to “gut feelingˮ than can be substantiated by caucusing or empirical grounding alone. When considering whether to transition from analog to digital telecommunications, AT&T justified that the existing analog technology was economically superior, and decided to not pursue the local digital switching market. Northern Telecom started developing the DMS-100 digital switch in the late 1970s and caught AT&T off-guard, as digital had become fashionable in the age when digital watches were emerging. The market perception of value trumped the engineering analysis. Evolving an existing product wasn’t enough: it was a matter of launching a new product line. Though there were intense discussions of these issues at the engineering level in Northern Telecom, it was ultimately a management decision for them to pursue digital switching out of a hunch and vision. They beat AT&T to that market in 1979. [2]

In an enterprise that develops multiple products, it is awkward for existing Scrum Teams to deal with strategic issues related to the lifetime or very existence of a team or product. For example, decisions in a scaled organization (producing multiple products) include collective considerations, such as responsible distribution of risk-taking across different products at different times. While Product Owners can take responsibility for a product, they cannot levy accountability on themselves. They are unlikely to have an adequately objective view to defund their own product when business sense dictates that they should. So individual products may themselves not have the scope, resources, or fallback ability to take major risks.

Scrum Teams emphasize ongoing kaizen, but kaizen emphasizes ongoing, local, incremental change. Sometimes a product or even an enterprise must go through discontinuous changes to survive. Extreme cases include Sun Microsystems slimming down its hardware business, Nokia going from making rubber boots to making cellular phones, and Toyota going from making weaving machines to making cars. IBM went from 1985 hardware sales accounting for almost three quarters of their income (in which software was a bundled component: see [3]), to a services organization where 2015 hardware sales were less than 10 percent of the income. [4] In 1986, management decided to boost its services business from 25 percent of its income to 40 percent of its income within six years ([5], p. 52).

Product Owners and Scrum Teams may be blind to such opportunities because they usually focus on managing risk through the incremental changes of kaizen. They may not want to mitigate risk by killing a product—namely, their own product. Team members may view radical change—called kaikaku in Japanese (see Kaizen and Kaikaku)—as a threat. Any single product organization may feel that great leaps such as those of the above examples exceed their risk appetite. If an organization pushes all responsibility for improvement into individual products or onto the lowest-level team, the result can be several locally optimized products that ignore opportunities for broader product or business synergy.

Managers are often present in the organization at the outset of an agile transformation; they may even initiate it. And they want to help. Teams that have been taught they are self-managing often view such management help as unwelcome. A manager keeps meddling in the affairs of the Scrum team, distracting the team, and generally becoming a nuisance. In extreme cases, the manager might even take on technical work or tell team members how to do their job. Wayne Rosing disposed of all such managers when taking the reins of vice president of engineering at Google in 2001, and had all 160 or so of them report directly to him, as he tells in [6]. Yet Rosing took this decision as a manager himself: somebody has to ignite discontinuous changes if an organization is to move forward on more than just local optimization.

Therefore:

Sustain a management function that can act from a position of power to initiate, and take responsibility for, radical changes in the organization, and deal with impediments that may be too weighty for the ScrumMaster or Product Owner in the Scrum Team. Scrum Teams manage themselves in all matters of tactical and most strategic product direction, functioning largely as Autonomous Teams. Scrum Teams interface with managers in a weekly MetaScrum event (typically through their Product Owners), but managers do not take part in other Scrum events.

While Scrum Teams manage themselves to chart their own kaizen direction, management will seek opportunities to challenge them with more radical kaikaku changes ([7]). As such, managers can play a key role in innovation: of thinking in directions that product management (the Product Owner) might find threatening to its own existence.

Great managers fill a servant leader role, yet they carry more power than a ScrumMaster by virtue of their position. A manager might intervene to resolve conflicts between Product Owners of different products. And managers can use their power to set policy that charts an organization on a strategy to achieve the Greatest Value. For example, management might remove the accountability for a given product direction from an existing steering board and assign it to a Product Owner willing to take on that responsibility. On a day-to-day basis, management may serve as the last escalation step for impediments that stand in the way of delivering product; their station of power and resources can often resolve problems in ways inaccessible to the Scrum Team.

Managers can powerfully fill a facilitating and coordinating role in large organizations supporting multiple products. They can also use the power of their position, and potentially their access to corporate resources, to serve the Scrum of Scrums and MetaScrum in resolving urgent impediments. If an impediment such as friction with an external supplier is holding up the Sprint, the MetaScrum may escalate to management to ask their support in resolving the issue.

A manager can also fill the role of a Firewall (see Firewall) to run interference against stakeholders who would interfere with the team. Again, this is traditionally a ScrumMaster responsibility, but managers might be more effective at managing this problem when it involves parties outside the organization.

A handful of additional management roles may take stations leading Birds of a Feather groups, particularly with respect to the traditional activity of career growth. Such managers close to the teams may deal with personnel development and administration.

✥ ✥ ✥

The enterprise can now manage risk from a perspective of broader oversight and objectivity greater than any single Product Owner brings to the table. Overall corporate-level innovation and efficiency can more readily improve. Product Owners retain responsibility for risk management and decision-making at a level commensurate with their scope of influence and of product content control: that of their own product. Management can nonetheless raise the risk appetite for the enterprise with radical redirection, recombination, or other action whose scope is broader than a single product. If a product is languishing, there may be a need to kill it (see Product Wake) and to free its people to work on other, perhaps new, products. This may offer an opportunity for global improvements that might otherwise stop at local optimizations within the kaizen scope of a Product Owner. For example, the broader view might discover that one product is cannibalizing the market of another, and that the net benefit to the market and realization of the highest value (see Value and ROI) will result from stopping production on one of the two products.

One reason that management can take the risk to strike out in radical new directions derives in part from their oversight of a broad portfolio of products that can take up the slack for each other, and in part from their intangible talent for having “great hunchesˮ that have propelled them into their position (see “Liquid Networks” in [8], and [9]). The higher management are in the organization, the more they augment rationality with decisions from the gut, as Gerd Gigerenzer notes in “Leadership and Intuition” ([10]). They can remove organizational impediments and bring the organizational structure in line with Scrum goals. For example, management may initiate a policy to remove product direction decisions from a sales and marketing organization that has become powerful, and shift the responsibility to the Product Owner. Again, drawing on the Nortel experience, we find this:

What was different about Nortel was that even managers and directors at the most senior levels were prepared to, and indeed were used to, thinking in an open and challenging manner about ways of working and ways of organizing and were far more willing to question the continuing relevance of current portfolios of products and services. At all levels they took a much more playful and expansive approach to thinking about organizations.

...They recognized a number of paradoxes and seemed prepared not only to live with but to apply these paradoxes to the management of organisation [sic] and innovation.

...They suggested that incremental innovation could be achieved by traditional organisational structures but that radical innovation required an organisation that was capable of moving beyond current structures. (From [11], ff. 46.)

Also, managers provide a locus of both strategic and tactical coordination and support in large organizations. Empowerment was a buzzword of the 1980s—a kind of cult of Autonomous Teams. Whereas managers originally supported teams with coordination and facilitation, research at DuPont, AT&T, and other large companies found that empowerment destroyed valuable connections between teams ([12]). Management served a valuable function that Autonomous Teams, taken to the extreme, destroy. However, keep the management population small: remember that Rosing from the earlier Google story had 160 direct reports with no intervening managers. As in Rosing’s case, this likely means that much of the existing management population may need to find new roles within the organization.

In fact, Project Oxygen at Google reinterpreted the role played by those titled as managers so that they functioned more as coaches than managers ([13]). Google recognized that good managers do not micromanage, that they communicate effectively, are caring yet productive, and that they focus on growing their people’s careers. While these traits characterize great managers in a traditional environment, a great ScrumMaster fills this coaching role on a Scrum Team.

On a day-by-day basis, the Scrum Team can invite managers to remove obstacles that stand in the way of delivery. This prevents the team from having to create work-arounds and helps resolve structural problems instead of leaving it to development to fight symptoms.

Note that management should be seeking synergy between products that each already have their own Value Stream. This pattern is not an excuse for management to subcontract parts of a product development to multiple vendors, unless each component already has market standing (e.g., as a commodity) in its own right. Unless there are economies of scope for the company as a whole, whereby several development efforts might share the intake from an external vendor, individual Product Owners should manage such subcontracting arrangements.

Management may decide that a particular business strategy (like IBM’s dominance in selling iron and copper) has come to the end of its useful life, and may decide to stop work on such products except for warranty replacement and minimal maintenance. That frees the business to move in a new direction (i.e., selling services, consulting, outsourcing, the Cloud). It is unlikely that the hardware Product Owner would himself or herself take the business in what he or she perceived as a suicidal direction, even though a broader business perspective may view it as for the greater corporate good. Management can start a new replacement business, driven by a Product Owner who brings a Vision suitable to the new direction. This is a radical, kaikaku change.

Of course, managers work closely with Product Owners on all such initiatives. The main difference between Product Owner and manager influence and activity lies in the scope and extent of a change: largely, the split between kaizen and kaikaku. Managers interface with the Scrum Teams in the MetaScrum, so managers interface primarily with the Product Owner role in Scrum. The MetaScrum is one forum that helps the manager keep in touch with what is going on in the organization (transparency and sharing information), and vice versa. It gives regular formal management access to the Scrum Teams. Managers should not otherwise intervene in Scrum events.

Managers become the focal point of scaling. Rather than scaling a product, managers scale the enterprise and facilitate the interactions between parts of the corporation. A Product Owner, and not a manager, heads each product, with a very thin and narrow veneer of management at the next level up. It is an impediment if managers come to need management from other managers. Again, going back to the role Northern Telecom managers played in innovation:

Nortel is very flat. You won’t see much hierarchy in the place... you will find champions all over the place at all sorts of levels. ([5], p. 50.)

In a large organization, managers can help fill a so-called “human resourcesˮ function that looks beyond matching the talents of individual candidates to an immediate need, focusing on broad competencies and an aptitude for learning. Good companies hire for the broad talent and hunger to learn that could benefit any one of a number of products over time and over a long career, rather than desperately hiring the talent that will enable any current product to meet its delivery goals. Closer to production, other management functions can support ongoing career development, knowledge management, and competency development, perhaps by leading Birds of a Feather organizations. Spotify has Chapter Lead managers who, while still being squad (Development Team) members, act as line managers within their Chapter. Some of their responsibilities include personnel development and salary administration.[14] Each Chapter is topically focused. This works well as long as the manager is not managing production; otherwise, the group reporting to the manager is likely to reflect that area of expertise rather than being a Cross-Functional Team.

Eric Ries says in [15] (pp. 2–3) that our belief in entrepreneurial success is often tied to the myth of “perseverance, creative genius, and hard work,ˮ whereas in reality he has found “that it’s the boring stuff that matters the most... Entrepreneurship is a kind of management.ˮ We often stereotype the ScrumMaster as being the chief cook and bottle washer that handles the dirty work, but everyone chips in on the daily chores in a great team. The ScrumMaster and Manager bear a bit more of this burden. Letting the Development Team do their thing builds the foundation to create great value. The unglamorous stuff is a distraction.

We relate the story of a Dutch company called Tony’s Chocolonely as an example. Some journalists discovered that most chocolate was produced by slavery and child labor (think: The Mist). They pondered how they could improve the world: “We lead by example and prove that commercially successful chocolate can be made without slavery and exploitationˮ [16] (think: Vision). “And not just our chocolate. No. All chocolate worldwide. When there is no more slavery in the chocolate industry, then we will have achieved our goalˮ [17] (think: Greatest Value). The business grew. With the growth of the firm came the distractions of finance, purchasing, and a host of other management concerns. They were not able to focus on their goal anymore. They reluctantly started a search for a manager who knew how to handle such concerns, but the founder felt those they interviewed were opportunists just in it for the money, like “used car salesmen.ˮ Part of the problem is that one of the founders, Maurice Dekker, was looking for someone just like himself, but he realized the ultimate irony was that his very skill set—or lack of a management skill set—was the root of the problem that the manager might solve. Eventually they started a collaboration with the person who is now their CEO, Henk Jan, and have since grown to be the largest chocolate producer in the Netherlands. [18] And the company produces chocolate in a slave-free value stream, as recognized by a 2007 Dutch court ruling. [19]

Some would-be management responsibilities often fall to the ScrumMaster, such as “managingˮ the Definition of Done. And the ScrumMaster can challenge the Scrum Team to kaikaku within the team’s realm of control. It is important to recognize that, unlike management, the ScrumMaster has no direct control over the team, but must work through persuasion and exhortation.

In the literature, one will find admonitions such as “management should create a good (safe, supportive, etc.) environment in which the team can work.ˮ Maybe. Managers have less ability to improve a team’s sense of safety than they have to destroy it. Pointing to such a responsibility implies that the Scrum Team has lost control over its environment, or perhaps that it never had such control. There is a balance to be struck here, but it is better to err on the side of recognizing the team’s autonomy over things it can control, and for management to focus on issues largely outside the reach of the team’s sphere of influence.

Traditional managers must take care not to fall back into their former activities once they start evolving their role under Scrum, particularly if they interfere with the ordinary course of work of Product Owners or of the Development Team. Managers must, in particular, respect the Product Owner’s authority over product content and release. They must also respect the Development Team’s self-direction as to the how, the who, and sometimes the when of feature development. It is the ScrumMaster’s job to make such a situation visible when it arises and to initiate the conversations towards removing such an impediment. And though managers may have control over the team, such control is never at the level of individual product or release strategy. The strongest foundation of management power is the reluctance to use it, and using it sparingly.

The pattern Smoke-Filled Room foreshadows this pattern. Smoke-Filled Room testified to the fact that sometimes management has to make decisions without first broadly engaging everyone who would be affected by those decisions, but it wrongly equated exigency with secrecy. Managers can be a powerful force that can respond to precipitous emergencies and can sometimes more ably steer the big ship than a consensus process can. But, they should operate in trust and openness instead of acting as the kind of shadowy cabal implied by the earlier pattern.

[1] —. “management.ˮ In New Oxford American Dictionary, Angus Stevenson et al., eds. Oxford University Press, 2017.

[2] —. “Overview & Background on Electronic & Digital Switching Systems.ˮ Telephone World, http://www.phworld.org/switch/overview.htm, January 2013 (accessed 5 December 2017).

[3] Jiri Weiss. “IBM Boosts Sales Force, Accents Client Support.ˮ In InfoWorld 9(8), 23 February 1987.

[4] —. “How IBM Makes Money? Understanding IBM Business Model.ˮ R&P Research, http://web.archive.org/web/20180121141146/http://revenuesandprofits.com/how-ibm-makes-money/, n.d. (accessed 27 January 2019).

[5] John Gallant. “Software Pricing Strategies: Tough Times bring Independents to the Table.ˮ In Computerworld XIX(52), 30 December 1985, p. 52.

[6] Keith H. Hammonds. “How Google Grows... and Grows... and Grows.ˮ In Fast Company 69, April, 2003, https://www.fastcompany.com/46495/how-google-growsand-growsand-grows (accessed 5 December 2017).

[7] James O. Coplien. “Kaikaku Mind—The Concept of Radical Change.ˮ In Lean Magazine 15. Malmö, Sweden: Softhouse Consulting, November 2017, pp. 21-23.

[8] Steve Johnson. “Liquid Networks.” In Where Good Ideas Come From: A Natural History of Innovation. New York: Riverhead Books, 2011, Chapter 2.

[9] Gerd Gigerenzer. Gut Feelings: The Intelligence of the Unconscious. New York: Penguin, 2008.

[10] Gerd Gigerenzer. “Leadership and Intuition.” In Risk Savvy: How to Make Good Decisions. New York: Penguin, 2016, Chapter 6.

[11] John Storey and Graeme Salaman. Managers of Innovation: Insights into Making Innovation Happen. Wiley: 2004, ff. 46.

[12] Charles Heckscher. “The Limits of Participatory Management.” In Across the Board 54, Nov./Dec. 1995, pp. 16-21. Published by The Conference Board.

[13] David A. Garvin. How Google Sold Its Engineers on Management. Harvard Business Review 91(12), 4 December 2013, pp. 74-82.

[14] Ashley Hardy. “Agile Team Organisation: Squads, Chapters, Tribes and Guilds.ˮ medium.com, https://medium.com/@achardypm/agile-team-organisation-squads-chapters-tribes-and-guilds-80932ace0fdc, 14 February 2016 (accessed 4 December 2017).

[15] Eric Ries. Lean Startup. New York: Crown Business, 2011, pp. 2–3.

[16] Api Podder. Amsterdam-based Tony’s Chocolonely Brings Mission of 100 Percent Slave-Free Chocolate to the U.S. My Social Good News, https://mysocialgoodnews.com/amsterdam-based-tonys-chocolonely-brings-mission-100-percent-slave-free-chocolate-u-s/ (accessed 28 January 2019).

[17] —. Tony’s Chocolonely Annual Report 2016/2017, https://tonyschocolonely.com/storage/configurations/tonyschocolonelycom.app/files/jaarfairslag/2017-2017/tc_jaarfairslag_2016_en_totaal_01.pdf (no longer accessible; accessed 8 June 2018).

[18] —. “Z Doc: TONY, Van Chocoladecrimineel Tot Wereldverbeteraar.ˮ Documentary on Dutch television RTLZ, 20:30 - 22:00, 11 December 2017, https://tonyschocolonely.com/nl/nl/doe-mee/tony-de-film (accessed 28 January 2019).

[19] —. “Tony’s Chocolonely.ˮ Wikipedia, https://en.wikipedia.org/wiki/Tony's_Chocolonely (accessed 17 December 2017).

Picture credits: Shutterstock.com.