Scrum is Agile Leadership – Part 3
How does the team lead?
In the first two parts we looked at the story of two companies to see how the Scrum Master and Product Owner provide leadership. These roles are integrated in a leadership system that develops over time. This story continues in this instalment, which is dedicated to the team – the most important role with leadership responsibilities.
What motivates people? Autonomy, mastery and purpose1
For the first few years of its existence, nobody at the start-up gave really serious thought to the topics of leadership and management. Everything just seemed to fall into place; it all seemed perfectly natural. New ideas were pursued whenever someone found the enthusiasm to do so. And, because the purpose of an activity is a significant factor in generating enthusiasm for it, everyone was driven to focus on responding to customers’ needs. In many cases, it would probably be fair to call this experimenting; whether or not a customer need actually existed was only ever a theory to begin with. As a result, new technical solutions were developed with wild abandon before being trialled – and then often discarded. The team decided to consult experts. If the proposed solutions had been effective, these experts might well have joined the team anyway because, as we know, enthusiasm is infectious.
You cannot not lead2
Parts 1 and 2 have shown that this naturalness was at risk of being lost following the initial growth phase. The Scrum framework, and later the LeSS framework, had helped employees to preserve this naturalness during the start-up’s early years. With this in mind, it is wholly understandable that all of the work was being self-managed3 by members of the team, even – and perhaps especially – when this meant working closely together with other teams. This daily work functions all the better when each team has the ability to bring about the necessary decisions at the factual level – or to accept such decisions. The Scrum Master therefore made arrangements for each employee to receive leadership and communication training. This made a significant contribution to improving the team’s performance. > The Product Owner does not lead the team to make decisions; instead, the team leads the Product Owner to make decisions
Above all, teams serve to produce *solutions** that boost customer satisfaction. This includes developing new functions as well as manual servicing and a personal service. As a result, there are no comprehensive IT operations in the conventional sense; instead, each team looks after a shared product and thus also takes care of support requests. This sharpens the perception of true customer problems. The Product Owner and the teams have developed a good understanding of when new findings and insight from their work with customers needs to be fed back in order for critical decisions to be taken for the company as a whole. The path to developing this understanding was long and difficult at times, but is now paying off for the company. To this day, not a single employee in the company has the word _manager_ in their job title. Instead, every employee is a leader in themselves.
Example: Medium-sized company
Agile is the ability to respond to change4
As outlined in part 2, a requirement area 5 at our medium-sized company has a lot of aspects in common with a start-up. All teams have accepted the responsibility for developing a product and ensuring stability. Consequently, the employees regard organisation and coordination on all key cross-cutting topics as self-evident. This happens in so-called communities of practice (CoP) 6. These are informal groups who come together to work on cross-cutting topics such as architecture, operations, testing, safety or usability. If necessary, these communities can be moderated by a Scrum Master; however, content management and responsibility for results lies entirely with members of the community. The community is therefore made up of team members sent by individual teams.
Hierarchies are good; no hierarchies is even better.
Of course, our medium-sized company has more than eight teams and there is great need for coordination across requirement areas. The teams also establish direct channels of communication and communities in this regard. However, not all of the company’s employees are working in line with the new principles – not by a long chalk. This results in waiting times, misunderstandings and, of course, mistakes. Compared to other cultures, a great deal of time and effort is spent translating issues, in both directions. Anything the teams do not take care of is still handled by those in management positions, in so far as they organise the work of others. People in these positions are faced with a near-impossible task. On the one hand, they are responsible for ensuring work is coordinated; on the other, they must not stand in the way of self-organisation (or self-management), all while avoiding rendering themselves redundant. These are often employees with a wealth of very specialist experience who have been at the company for many years. They might well find themselves asking serious questions. What’s going to happen to me? Do they still need me here? Fortunately, the COO and CEO identified this and formulated the following principle for the transformation: Roles may change, but jobs are guaranteed. This statement alone made it possible for many of the company’s top performers to leave their managerial roles to one side and focus on what they do best, by providing specialist leadership as a team member in a team working alongside all the other teams.
They achieve this by
- Creating solutions
- Managing work
Synonyms of managing include coping, accomplishing, arranging, overseeing and leading. In a professional context, this includes planning, implementing and monitoring work. Self-managing is sometimes also referred to as self-organising. ↩︎
Breaking down the word responsibility, we can see it essentially means the ability to respond. For more details of why only you can take personal responsibility – and how – see: The Responsibility Process ↩︎
An area in LeSS Huge in which up to eight development teams work on a product. ↩︎
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