✥ ✥ ✥
Without deep understanding of Scrum theory and its principles it is very hard for an organization to succeed with Scrum to create the most valuable product. And although an organization may understand how well it is performing, it doesn’t always know how to improve. When we see ourselves accurately, it is sometimes clear what we can do to improve. But often it is hard to see what the problems could be if you are part of the problem yourself, a person with a detached view can make us aware of our own blocking behaviors and thinking, so that we can then decide to do something about them.
Teams adopt Scrum as a kaizen to improve quality, interval, and throughput. Scrum works because of an extensive, powerful, and profound system of principles, theories, values, and foundations that combine in complex ways to support complex development. “Articulated Scrum” — the level of artifacts, roles and events at which a typical practitioner usually understands Scrum — are only a caricature of richer underlying principles. These richer principles are rarely understood but are fundamental to success with Scrum.
Removing organizational impediments, facilitating arguments, organizing group events and courses, keeping the library current, bringing career opportunities to the group — all of these are activities of a healthy team. Some of this work responds to inputs from outside the Scrum Team about shortcomings in meeting stakeholder expectations; some are opportunistic chances to improve from within. Many of these activities are time-consuming “distractions” that neither the Product Owner nor the Development Team are eager to add to their responsibilities. So these tasks often fall to other roles like clerks and managers. Managers bring with them a mantle of control, and a traditional clerk responds to the control and direction of the team member requesting some service. In both cases, it entangles those involved in the activity with the other role, and dilutes individual autonomy in bringing such work to completion.
There are deeper structural problems that owe to the focus that the Product Owner and Developer roles respectively bring to their jobs. While being focused on ROI or on completing a Sprint, it’s easy to lose sight of the larger picture. It becomes difficult for individuals to separate their own interests from those of the team, or of product development as a whole.
One of the common casualties of this myopia is the process. The Japanese roots of Scrum tell us: “build the right process and you’ll build the right product.” Yet if you are focused on the product, whether from a business strategy or development perspective, it’s easy to forget the rigor and attention that process improvement deserves. It takes a lot of discipline for a team to police itself instead of rationalizing away agreed process standards. For example, a Development Team may see no immediate consequences from omitting compliance to a couple of minor development standards, or skipping a couple of tests, or of letting that one minor defect reach the market. A Product Owner may interrupt development to impose his or her will just this once. The team might be so myopic as to never have taken the initiative to learn Scrum or to make any investment at all in process issues. Such conduct might be in line with the usual responsibilities one can rationalize for these roles, but it can be destructive in the long term.
It’s easy for an ingrown team to take ownership of its accomplishment and to not wait to react to consequences. When implementation is done, it takes patience to wait for testing; when testing is done, it takes time to wait for market feedback. Even if the team has put feedback loops in place it’s too easy to be lulled into a sense of complacency if the feedback is constant. “The quality is O.K.; our defect backlog hasn’t changed from 2,000 defects for 18 months.” If each role is focused on its own job — e.g., of setting product direction or delivering what was asked — it may receive no other feedback about product quality.
It’s easy for a sense of autonomy to become a sense of isolation. A Developer may feel that his or her concerns are likely to fall on deaf ears even if others in the same role speak in concert: after all, they are only Developers and stakeholders often dismiss their insights on strategic issues. The Product Owner also needs an advocate.
And a team that is focused on pleasing the stakeholders, or on doing a good job, or on meeting a schedule, can often lose sight of its own needs. Scrum has two products: the deliverable, and the team. While everyone may be a good citizen and be attentive to doing their job, team health and growth are crucial to the well-being of the enterprise. Everybody could do this, but something that is everybody’s responsibility is nobody’s responsibility.
Introduce a ScrumMaster that guides and leads the Product Owner, Development Team and broader organization in understanding the Scrum framework, its principles and values. The ScrumMaster defends the Scrum process and nurtures the organization to successfully use Scrum. The ScrumMaster acts as a guide to explain the deeper underlying principles that might be at play when a given impediment arises, and can interpret these principles together with the team, to support them in identifying and implementing a solution.
The ScrumMaster guides the organization and Scrum Team to reflect and improve; helps to resolve impediments and to improve the Scrum processes. This is why even top performers in sports, music, entertainment, and other fields usually have personal coaches. Interestingly, the coaches are not necessarily the top performers, but are particularly adept at teaching, observing, and challenging their protégées to ever greater heights.
The ScrumMaster helps Product Owners succeed by guiding them. For example, suppose the Product Owner does not order the Product Backlog properly. The ScrumMaster could simply ask the Product Owner to order it, but a better approach would be to provide subtle guidance on how the Product Owner should go about putting PBIs in order. The ScrumMaster might ask a question like this: “We will be planning our next Sprint in the next few days, and the Development Team is wondering what we should work on next. It appears that items A and B are both important, but we don’t know which is most important. You have insight into the company’s vision, business model, and finances. You also have a good perspective on user needs and desires. Based on these, can you figure out which we should work on now?” (This approach has overtones of flattery, but it’s not the purpose. Instead, it shows the Product Owner how and why they are valuable.)
“Doing nothing” may be the most important activity because every time the ScrumMaster ‘solves’ a problem or makes a decision for the team, an opportunity for team growth is lost.
✥ ✥ ✥
The ScrumMaster is not the manager of the team and has no authority over the team’s decisions or actions. The ScrumMaster may never direct the team about what to do or how to do their job, but must employ effective persuasion and motivation. One key job of the ScrumMaster is to fight complacency (see Pop the Happy Bubble). The only direct power that a ScrumMaster can wield is to remove a disruptive person from the team (see Remove the Shade).
A way to characterize the overall role of the ScrumMaster during the initial phase of Scrum adoption, is as a coach for the Development Team and its members. The ScrumMaster is responsible for the Scrum process, and particularly helps the Development Team to deliver a Regular Product Increment at least every Sprint. This is hard enough for teams starting with Scrum and is a good initial goal to strive for. Ideally the Scrum Team selects the ScrumMaster itself, and selecting the ScrumMaster is often the team’s first act of self-organization. In any case, the ScrumMaster is a servant leader to the Scrum Team.
The pattern Producer Roles explains that team members typically are either “producers” (people who directly contribute to the ROI of the organization), or “supporters” (people who help the producers do their jobs). The ScrumMaster is the quintessential supporter: everything the ScrumMaster does should focus on helping the rest of the team (who are typically all producers) be effective.
The ScrumMaster serves the team out of empathy and care for the team and its objectives, but should not be assimilated enough into the team to dull his or her edge of objectivity. It is a balance. The ScrumMaster should be enough within the social closure of the team to retain keen awareness of how things are going, but should not be enough part of the development process to lose external objectivity. One consequence of this perspective is that it may not even make sense for a single person to be part-time ScrumMaster and part-time Developer. Part of maintaining the balance is to avoid becoming aloof, or being perceived as aloof. The ScrumMaster should strive to be present to support and serve the team as unexpected impediments spontaneously pop up. See Small Red Phone.
The ScrumMaster is sometimes the face of the team to the rest of the world. In this capacity the ScrumMaster can help protect the team against unwanted distractions (see Firewall). Anyone from outside the Scrum Team wanting to confront the team as a whole, or a team member, should go through the ScrumMaster. The ScrumMaster protects the team from unwarranted threats and criticisms while distilling what information is of use for the team to improve. And the ScrumMaster may in the end facilitate a direct communication between such outside parties and the team. However, in no way should this mean that the ScrumMaster is the communication channel for the team. On the contrary, team members should communicate freely and frequently with anybody they need to. But occasionally a single contact point is expedient, and the team should inspect and adapt in having the ScrumMaster fill that role.
Again, an important role of the ScrumMaster is to help the team understand the “whys” behind the elements of Scrum. The ScrumMaster is the standard-bearer for the Scrum Team and organization to guide them within the Spirit of Scrum (see The Spirit of the Game).
The nature of Scrum is that it is a high pressure environment. Each Sprint can feel fast paced and even frantic. Over time, this can actually demotivate individuals and cause burnout. The ScrumMaster encourages team members, praises small successes and ensures that the Development Teams keeps operating at a sustainable pace. The ScrumMaster role itself is a high-pressure job. To prevent burnout the ScrumMaster must seek coaching.
An important result is that Scrum at the team level impacts the organization as it expands from just tactical within the Development Team to a more strategic role. Thus it can help change the culture of the entire organization.