Scrum Leadership
Andreas Schliep
Product Owner @ DasScrumTeam AG | Certified Scrum Trainer - I train Scrum Coaches and coach Scrum Trainers.
Pit and I held a nice session about the leadership aspects in Scrum at #XP2023 . We demonstrated how the accountabilities in Scrum interact in their leadership triangle.
In the meantime, we find the term "agile leadership" everywhere. In any case, already beyond software development, where the term "agile" was chosen in the first place as a summarizing characteristic for a series of lightweight development methods. The signatories of the "Manifesto for Agile Software Development" would probably not have dreamed that there are already positions for "Agile Leaders" in various companies today. In this respect, it is convenient for a trainer or author to attach themselves to the topic. Hardly anyone understands what is meant by it, and all personal favorite concepts, from working with people to developing products and changing organizations, can be included.
The term "business agility" makes Pit and me feel particularly funny. After all, what else is agility supposed to be about? What are we doing the whole thing for, anyway? So a new term is highlighted that should clarify something that should have been clear from the beginning: product development is a team game. And it's a dynamic one, not a synchronized swim. It's about moving beyond fixed processes and established tools to focus on individuals and how they work together. It's about delivering value rather than mountains of printed paper. It's about solving problems together within the business - that is, with customers, users, and stakeholders, rather than clinging to the wording of a contract. And most importantly, embracing change rather than blocking it out to stick to a plan. What else is that but "business agility"?
In our XP2023 presentation, we showed how we understand Scrum as Agile Leadership, namely as leading an organization according to the agile values and principles by means of the accountabilities, events, and artifacts of Scrum. So in the way, we are living in our own company. However, our company also consists of only one team, which we have organized according to Scrum, i.e., essentially self-managed, under our direction. And if this constellation is still small and manageable, it already brings us to the essential, seemingly contradictory statements.
Scrum is not enough
As a training provider for Scrum and related topics, we know the limits of Scrum very well. We develop products like our pieces of training, but also the website and the learning management system. For this, the Scrum rhythm is implemented almost analogous to Scrum Guide. But we are also a training service provider. That entails a whole range of additional planning, organization, and support activities. Apart from that, we also take care of corporate training sales and some non-profit side projects. So it is clear that the work mode cannot be driven by Scrum alone, but we use the techniques of #Kanban .?
Scrum also does not appear as the only method in our software development, i.e. the adaptation of our administrative systems and the addition of the website and learning management. The agile development practices Continuous Integration, Test Driven Development and Refactoring, to name just three, come from eXtreme Programming. So again a task for which Scrum alone is apparently not enough, or is it?
Scrum is enough
In today's understanding of Scrum, we already have much more flexibility in planning and rescheduling the sprints. We have always implemented variants of Scrum where the team also had to take care of different kinds of tasks. Even before David Anderson condensed his findings into the Kanban method. So Scrum has always "been able" to do DevOps:
The DEV% – the share of work that can be scheduled in Sprint Planning from the Product Backlog – is jointly determined by the Product Owner and the Developers. The above example is more in line with our work at DasScrumTeam. We have a slight overhang of service tasks, mostly accompanied by work that cannot be planned in advance.
Development practices are not a completely new item in the Scrum world either. eXtreme Programming and Scrum have always evolved side by side. Jeff Sutherland himself insists that certain practices are introduced to Scrum teams in the development of technical products. Not to mention, Scrum has always been the organizational framework, the basic structure for integrating, re-introducing, and improving any practices.
So even though we use many different approaches, at the core, we are a Scrum team delivering value according to the sprint rhythm in the empirical process - creating transparency, reviewing, and adapting.
So what many voices in the agile scene like to loudly proclaim – that "Scrum is too inflexible" – is based on a lack of background knowledge and a conclusion that is too short-sighted. Scrum is extremely flexible in the choice of application areas and associated processes and practices. Scrum's leadership model must, therefore also work in contexts far beyond software development.
Scrum Leadership in small or medium-sized companies
Even though companies with less than 10 employees are not uncommon, companies with up to 300 employees still tend to be among the smaller representatives, compared to large corporations with thousands or tens of thousands of employees. How is a management model based on Scrum, which is based on a Scrum team, supposed to work with considerably more than 10 employees?
Well, we can hardly imagine combining 300 developers in a single team. Yet the basic idea behind it, that all employees see themselves as part of a social system for creating value is not so wrong. We've heard of companies of this size having an "all-hands" meeting at least once a week. In effect, the company's "scrum of scrums." Employees go back to their teams afterwards.
Scrum leadership is based on three forces:
Product Leadership: The Responsibility of the Product Owner
So in a classic stakeholder diagram, you would place the Product Owner as the Scrum Leadership role with the most influence and contribution to the product.
We can already hear many voices saying, "But at our company, the Product Owners are in the Development teams, we don't have just one." To that, we counter that we're talking about the actual Product Owner here, the person who has to be accountable for the product decisions:
In the GrooveX case study, we show how the CEO fills the overall product owner role here. However, it may well be that the responsible product owner calls in support, for example if:
Product leadership can also be implemented in medium-sized companies by means of Scrum. What about the other leadership tasks?
Social leadership: The responsibility of the Scrum Master
There are different opinions on whether organizations can be seen as social systems. If we understand a social system as a combination of people and their relationships that have a common purpose and pursue it through their interaction, then small and medium-sized companies are definitely within this definition range.
Classical line management is primarily concerned with how responsibilities are delineated. The hierarchy node next to me has different tasks than I do; the one above us has the collective responsibility, and the branch in my position has to let me tell it something. This hierarchical division is particularly suitable for ordered contexts - i.e., where problems and their solutions can be easily broken down into sub-problems and responsibilities.
When we follow agile values and principles, we are more interested in collaboration than task delineation. This means that we are dealing with a different kind of social system view.
The systemic view and its consequences are the responsibility of the Scrum Master. While classical leaders exercise leadership within the system through their position, Scrum Masters work on the system through facilitation, coaching, mentoring, training, and consulting. But who are they advising? The Agile Leaders?
Here we come to the distinctive feature of Scrum Leadership. It comes without managers - an "Agile Leader" is a manager with a nicer job title.
领英推荐
Working Leadership: The Responsibility of the Team
In many ways, the term "Developer" is problematic for all those who do value-added work in Scrum. It is too easy to confuse the term with software developers. In many cases, this confusion leads to constructs with "Scrum Teams" consisting of software developers and separate organizational units of business analysts, testers, or other specializations. Therefore, analogous to older Scrum definitions, I would prefer to speak of "teams" here. Because the leadership of the work - assessment, planning, coordination, reporting, process improvement - is done in Scrum by the team or teams.
A team is a special form of social group. Team members are not only connected by a common goal but also work together on it in a coordinating way. Teams can have the most diverse tasks, but they are characterized by the fact that they accomplish them together. Of course, in principle, some teams are led by managers. That is why Richard Hackman uses the term "real team." A real - or "genuine" - team works together on a shared goal, is responsible for its own progress, and manages its own work process.
Hackman likes to talk about "effective teams." Effective teams are real teams with an infectious sense of purpose, empowering structures, a supportive organizational framework, and expert guidance in team building, motivation, coaching, and training. Real teams
How does this work without managers? That's where two factors, in particular, come into play.?
Product owners provide the goal setting. They provide the organizational framework for the work and support the teams in creating value through their business perspective.
Scrum Masters take care of coaching, facilitation, and training and build enabling structures. They support teams in formulating and improving their work and team processes.
So in Scrum Leadership, we rely on the self-management capabilities of teams rather than introducing excessive control and reporting hierarchies. This works with one team and with a small and medium organization of teams.
But what about large enterprises?
Scrum Leadership in large companies
Perhaps large companies can't be seen as a single system at all; divisions, departments, or subgroups often pursue their own goals. Nevertheless, it makes sense to look for the connecting elements. And in large companies, we find them even more clearly than in SMEs on the three levels:
Klaus Leopold uses the metaphor "flight level" for these levels. Whether visionary-strategic, tactical-coordinating, or value-creating-organizing, the visualization of the work is in the foreground for him, independent of the respective process. However, there are feedback loops at all levels - as usual in Kanban - which is used in regular cycles to provide transparency, review, and adjustment.
This almost sounds like Scrum, even though Klaus does not assume specific roles, artifacts, or events. But let's imagine that we break away from the misconception that Scrum teams can only deliver on Sprint Review. Maybe they don't even need to be called Scrum Teams. Again, we need leadership about the product and business goals, social leadership, and hands-on development and service management.
The working level - Scrum even without Scrum?! Service teams and business units can also benefit from Scrum principles and practices.
Recently, Belgian trainer colleagues presented vima , a Scrum-like process model for arbitrary business teams. The main problem with applying Scrum in teams that provide services or sell products rather than develop them seems to be the name of the Scrum artifacts - not so much the process itself.
Regardless of the type of work, there are always goals that can be planned for the long and medium term and how to deal with short-term challenges. That is why the current Scrum Guide does not speak of product development but of value creation:
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Practically, this may mean that the Product Owner's responsibility in a service or business organization is a little different from a team leader role. The goals need to be properly aligned with those of the overall organization.
Many organizations realize after a while with Scrum that they no longer need the existing organizational units based on the hierarchical division of labor in this way anyway. The real business challenges are met with true cross-functional teams. So sometimes, the supporting activities also migrate to the Scrum Teams. Which in turn also brings a great development opportunity for all employees.
So Scrum Teams are not components of a larger functional machinery, but self-managing mini-companies within the company. This is not to say that their own progress is at the expense of a larger goal.
The coordination layer - Large Scale Scrum and alternatives to large scale collaboration.
There is no official definition of scaled working with Scrum. Some see this as a shortcoming, while others develop their frameworks and models. We see it as an opportunity to design a team landscape that is built around the needs of the organization.
In large companies, we have all these variations and more. How many of the teams and organizational units actually interact in the same rhythm afterward, and how many go ahead in separate feedback loops, depends on the cohesion of the products or services.?
The control level - setting visions and goals, keeping an eye on overall progress - and doing it with work-in-process limits.
What seems complicated at the middle level is suddenly quite simple again at the strategic level. All it takes is the decision on which projects, product steps, projects, initiatives, or improvements - one does without. Prioritization is not simply the evaluation or ranking of goals and desires. As Klaus Leopold so aptly points out, in many organizations, it is completely ignored that one overloads a system if one wants to start all projects simultaneously. A strong Product Owner personality is needed at the control level because the product here is the entire company, with all value-creating and supporting activities.
In addition to visualizing the work - the value stream - it is also worth visualizing the value chain, especially at the strategic level. If, in addition, the information about components, activities, practices, and data is supplemented by their respective development stages, a very informative Wardley map of the current situation is obtained - brings good insights into sensible strategy decisions.
These processes are not so easy to accompany. Therefore the position of the Scrum Master as Executive Facilitator is recommended here. Together with the representatives of the value-creating units, the Executive Product Owner and Scrum Master form, to a certain extent, the real nexus team of an organization.
"Values and structures" instead of "thought control":
Probably we Agile coaches and Scrum trainers have helped to create the false expectations and assumptions that are anchored in the minds of many potential and actual Scrum users. It has happened to us as coaches, too, that we have told a participant - at least in our minds - "You're thinking wrong!"?
Dave Snowden addresses this misconception and the associated false hope that after a "correction" of the "mindset," everything would already work in his articles and lectures on the topic of "Rewilding Agile."It is presumptuous to demand from other people a change in their fundamental attitudes and beliefs. Instead, he says, one should provide suitable structures in which the desired behavior can better emerge. So instead of demanding someone to be "agile," we create framework conditions that favor decisions according to agile values and principles.
In Scrum Leadership, the Scrum process provides a large part of the framework. The Scrum Leadership triangle provides orientation around business goals, improving collaboration, and delivering value. Around this core, the Product Owner and Scrum Master - often in the form of CEO and COO - provide the basic framework.
Additional Resources
Improving the world by improving the people in it
1 年Any reason the SM and PO are depicted *outside* of "Team" here?