Scrum is Agile Leadership – Part 2
How does the Scrum Master lead?
Part 1 of these series used two example companies to show how Product Owners lead. The Product Owner is part of an agile leadership system (or management system) that needs to be developed for every organisation. Scrum provides a framework for this leadership system.
This part continues the story of both companies and illustrates how the Scrum Master leads.
Culture follows structure1
From the very outset, the start-up looked to Scrum as its leadership system. A major driver behind this decision was one of the company’s first employees – now one of its joint owners. She convinced the founder to establish an agile corporate culture2 and rely on Scrum to give the company a structure that would enable it to grow. She also convinced the founder that he should take on the role of Product Owner, which would see her take leadership responsibility as Scrum Master. Since then, the company has grown to some 50 employees. Above all, this growth also means a growth in the abilities of the teams. One of the Scrum Master’s duties is to develop these abilities ever further.
In some cases, new teams had to be created and staffed with new employees. New practices had to be learned – while some old practices had to be unlearned. The Scrum Master also needed to take appropriate steps when one employee was repeatedly unable to integrate into teams. She often did not perform these actions herself, and instead oversaw the process. For instance, decisions about new hires were ultimately taken by a group composed of team members, the Product Owner and the Scrum Master. Then, as the number of teams began to grow, so too did the number of Scrum Masters. At the point in time considered here, the original Scrum Master had been joined by a further five Scrum Masters. Together, they took on responsibility for optimising the entire organisation. Each Scrum Master now oversees one to a maximum of three teams. The decisive aspect, however, is that all the teams become better in terms of their joint output.
The Scrum Masters also dedicate themselves to different specialist areas, from overseeing the recruitment process to introducing and adjusting engineering methods, and from continuous coaching to product strategy and scaling up development.
Any organisation that designs a product will produce a design whose architecture is a copy of the organisation’s structure 3
One of the greatest challenges is the strong interdependence between teams and the need for communication this engenders. Though it might have been possible to find some kind of solution with 30 employees, this begins to pose a real problem as the company grows. Consequently, employees develop more and more isolated solutions that cannot be integrated globally into the product and therefore offer no value. Then again, if teams chose not to work on isolated solutions, they would constantly be forced to wait on the results produced by other teams. It is a dilemma that worsens with every new employee who joins. The only solution is to section the product architecture in such a way that the teams have as few shared activities as possible. As each product is unique, so too is the structure of the organisation designing it. Scrum Masters therefore need to work in close coordination with the Product Owner and developers and repeatedly conduct experiments with them to gain new insights into the product architecture and organisational structure. The guidelines and experiments of Large Scale Scrum (LeSS) provide a source of inspiration for global optimisation.
Example: Medium-sized company
In the first part of this series we looked at how the CEO – and therefore the most influential Product Owner – identified the Backlog in the company’s project portfolio and radically prioritised all active projects. He achieved this by calling on the Area Products Owners, all of whom are experienced and influential players within the company. Although this process was far from easy, it was facilitated by an external consultant and coach with many years of experience working with Scrum and agile practices.
A Scrum Master is a coach who takes responsibility 4
Now, with a new sense of focus, it became clear that the most important thing was lacking: functioning teams that deliver finished products. Teams had self-organised in many areas of the company, some of them using or having used Scrum or Kanban. However, these teams ran aground time and again when it came to the improvements they needed from the existing organisation. It soon became clear to the CEO that what was actually needed was optimisation of the organisation on a long-term basis. He made the external coach an offer he simply couldn’t refuse: the opportunity to become the new COO and take responsibility for the optimisation the company so needed. By accepting the position, he became the most influential Scrum Master in the company.
In his first action as COO, the new Scrum Master established a cross-functional group from all areas and all levels of the company. It brought together team members and Scrum Masters from the various Scrum and Kanban initiatives as well as managers and the CEO. Together, they drew up a strategy for the company’s transformation, made up of defined targets and measures. Just like all other major investments, the strategy was incorporated into the company’s Backlog and prioritised by the CEO. Everyone at the meeting was acutely aware that it would not be possible to convert the entire organisation to Scrum in one fell swoop. The process of migrating to Scrum entails a significant risk of a functioning business being damaged. What’s more, strong and consistent leadership is essential until Scrum is eventually anchored in the company. However, the company simply lacked employees with the expertise required to do so. With this in mind, the decision was taken to make the change gradually. As change is always born of necessity, the COO and CEO decided to systematically migrate two projects to Scrum to act as beacons, guiding the transformation of the organisation as a whole. They recommended that other areas use Kanban to create transparency over their current working methods and then make small, gradual improvements by holding regular reviews. The COO and CEO also offered other forms of support, such as the option for areas to call in a Scrum Master as a consultant or coach, and the opportunity for managers to train and qualify as Scrum Masters themselves.
As it happened, the two flagship projects shared significant commonalities: 1. They both harboured significant strategic potential from a company perspective 2. There were a whole host of unknowns when it came to their implementation and the market 3. Their development could be broadly decoupled from the rest of the organisation
In effect, the two projects were hardly different to the example of the start-up. Instead of the start-up’s CEO, there was an Area Product Owner. What’s more, there were Scrum Masters who worked with the COO to further optimise the work system. In some cases, managers with experience of HR development took on leadership responsibility as Scrum Masters. Interim Scrum Masters and coaches were also brought in from outside the company to act as knowledge incubators. After five months, the first project’s product proved unsuccessful on the market and its development was terminated. By contrast, the second product was highly promising; after a year, the development organisation had grown to more than 30 people across 4 teams. By then, it had become clear that the project organisation would remain a permanent area of development. In fact, the word “project” is no longer used in this area – in the LeSS Huge system, it is known as a requirement area. The experience gained in both these projects is now being used to migrate other parts of the company to Scrum. In fact, the project that was aborted prematurely provided particularly valuable experience.
Although the product proved less successful, the teams were able to take the decision to terminate the project at a very early stage and thereby avoid throwing good money after bad. In addition, the company’s employees gained a great deal of experience of working in an agile organisation – experience they can now apply in other areas. The Scrum Masters have taken on responsibility for the ongoing transformation process. The next significant change in product development will be [LeSS Huge].11 Many of the elements are already in place, such as the central Product Backlog for the entire company. Heavily service-oriented parts of the company dealing with complex processes, such as production, operations and accounting now use Kanban and lean management practices in a sprint rhythm. Nevertheless, one or more Scrum Masters are still required to provide leadership – it is just that these leadership roles are not often given that name.
They achieve this by:
- Optimising the entire organisation
- Developing teams
Agile leadership is primarily about acting with the aim of establishing a system of leadership that causes an organisation to become and remain agile. A Scrum Master will see this as their primary responsibility. The two other roles in Scrum draw on the Scrum Master’s service to fulfil their own leadership duties.
The Agile Manifesto provides a definition of an agile culture (sometimes referred to as simply agile). For a definition of the principles applicable to an entire company, refer to the Scaled Agile Lead Development Principles (ScALeD). ↩︎
I originally came up with this idea as a riposte to Andreas Schliep’s statement, "A Scrum Master is an Agile Coach who isn’t there yet.". ↩︎
About the author
Peter has set himself the task of creating companies that deliver value for their customers and employees. That was also the motivation behind his decision to found DasScrumTeam. Peter is a passionate Scrum Trainer (Certified Scrum Trainer, CST) and consultant with a solid background in engineering. Since 2007, he has trained and advised a wide range of development teams, specialist departments, project managers and those in leadership positions, helping them to apply the Scrum framework, agile planning methods and software engineering practices. Peter is a graduate engineer (Dipl.-Ing, TU) specialising in electrical engineering and information technology.
- Experience with Scrum since 2004 as Team member, Scrum Master, Product Owner, Coach and Trainer.
- Served as ScrumMaster in internationally distributed Scrum Teams
- Co-founder and Product Owner at DasScrumTeam AG
- Key interests: Agile companies and Scrum beyond Software