Empowering Teams: The ScrumMaster's Role

By John Hill

The number of “unempowered” teams alleging to be doing Scrum is appalling! Two significant factors often prevent Scrum teams from becoming empowered, ultimately leading to their failure:

1. Organizational command and control behavior
2. Specific ScrumMaster failings

Both of these factors are something a ScrumMaster can (and should) address.

Symptoms

You can tell a team knows they are powerless when you observe them going through various Scrum "motions." These motions include the following dysfunctional sprint meetings:

• Sprint Planning Sessions. Symptoms include managers or ScrumMasters:
  • Questioning (or influencing) team task estimates.
  • Directing the order in which tasks should be completed during a sprint.
  • Directing which team members should be assigned to specific tasks.
• Daily Scrums. Symptoms include:
  • Providing status to the ScrumMaster instead of providing status to the team.
  • Zombie-like monotone responses, such as "I did this. I will do that. I have no impediments." Daily Scrums of this nature rarely lead to the collaborative post-Scrum discussions where decisions are made and impediments are circumvented.
    • For a great discussion on how to get your daily Scrum back on track, see Stacia L. Broderick’s “Daily Standup Withdrawal (DSW) in Scrum Teams.”
• Sprint Reviews/Demonstrations and Retrospectives. Symptoms include:
  • Managers and/or ScrumMasters who take charge of the session and state their observations first. This often influences the team to stifle their best observations for fear of contradicting the manager.
  • Little meaningful feedback from the team. The result is that no “go-forward” improvements result from the sessions.
• General Meetings. Symptoms include team members that:
  • Ramble aimlessly.
  • Hijack meetings and won’t relinquish control back to the team.
  • Do not participate.
  • Get up and leave meetings.
  • Force their “expert” opinion on the team inflexibly.
  • Argue about everything.
    • For great techniques to handle these team meeting dysfunctions, see Jean Tabaka’s Collaboration Explained: Facilitation Skills for Software Project Leaders, Upper Saddle River, NJ: Addison-Wesley, 2006: 242-251.

Causes

"Command and Control" Style Managers (including ScrumMasters)

All of the problems described under “Dysfunctional Sprint Meetings” are caused directly by managers (including ScrumMasters) who usually come to Scrum armed with years of ingrained, directive behaviors. The ScrumMaster needs to work with these managers to get them to let go. It’s the ScrumMaster’s responsibility to educate management and help them understand that the process is all about trust. If team members cannot be trusted to determine their work, teams will never properly “commit” to completing a sprint goal, nor will they ever feel the desire to make the key decisions that they should be responsible for.

The ScrumMaster also needs to work with managers to help them to allow others to provide feedback during sessions before they chime-in. If the manager cannot be controlled in this area, they may need to be removed from the process.

If the ScrumMaster is the problem, then an agile coach needs to be brought-in to educate the ScrumMaster (or have the ScrumMaster removed and replaced if necessary).

I would also like to add another cautionary note. Converting line managers into ScrumMasters sometimes will not work. The team behaves as though the ScrumMaster is "the boss" and looks to that individual for guidance while doing Scrum. Teams thus feel that their power comes from the ScrumMaster, and not from the team. Converting "strong" project managers into ScrumMasters can be problematic for the same reasons.

In both instances, the team will likely provide status to the ScrumMaster during the daily Scrum, instead of using the session for its intended purpose of sharing status with the team. Fortunately, there are numerous exceptions where former line managers and project managers are now successful ScrumMasters (although this transformation can take a while).

General ScrumMaster Failings

I strongly recommend that ScrumMasters refer to the book by Jean Tabaka referenced above and make use of its wisdom. If a ScrumMaster is unable to resolve these issues, a professional facilitator should be consulted. In my experience, teams will never feel in control if members do not properly participate together in meetings as a cohesive unit. I therefore believe that it remains the ScrumMaster’s responsibility to ensure that these issues are resolved, even if by a third party.

Cure

To ensure team empowerment, the Scrum Master must work diligently on all of his or her responsibilities.

Resolve Conflicts: The ScrumMaster is responsible for removing certain barriers, including barriers:

* Between individual developers (or between any individual team members)
* Between developers and test engineers (especially when first working together cross-functionally)
* Between the development team and the product owner.

If the ScrumMaster does not have the skills to deal with team conflict, a professional facilitator should be consulted. A team will never be fully-empowered with even one dysfunctional relationship within the team.

Handling Impediments: A ScrumMaster must actually work to help remove impediments reported during the daily Scrum. If it looks like an impediment cannot be removed for some reason, it becomes a condition of reality. For these conditions, the ScrumMaster must work with the team to circumvent the impediment. If an impediment requires more than one day for removal, the ScrumMaster must communicate this information back to the team so that they know the ScrumMaster is making an effort on the team's behalf.

Protecting the Team: The ScrumMaster must protect the team from disruptive outside influences. (Examples include salespeople directly requesting estimates from team members for prospective clients, support staff directly contacting team members for help with customer bugs, consultants at client sites calling team members with installation, conversion, or configuration problems for a new installation, etc.) Even if a team member is truly needed in these situations, the ScrumMaster must provide a filter. The ScrumMaster must also protect the team from attending unnecessary meetings. Most meeting owners will be able to tell if a team member really needs to attend a meeting. If so, the ScrumMaster should still be the filter.

Conclusion

Scrum teams feel truly empowered when they understand that the ScrumMaster is actually looking out for the team and will protect the team from outside influences that can rob the team of its power. More specifically, the ScrumMaster needs to

• Eliminate (or sufficiently reduce) “command and control" management practices so that teams can run their own sprint planning sessions in the areas of task estimates, task sequencing, and task assignments, as well as run sprint reviews and retrospectives openly and honestly so that they actually make a difference going forward.
• Ensure that dysfunctional meeting participants are controlled, even if by a third-party facilitator.
• Ensure that barriers between team members are removed, even if by a third-party facilitator.
• Effectively work with the team to remove impediments, proving a level of true commitment to the team.
• Protect the team from stressful outside influences and unnecessary meetings, enabling the team to work together with reduced interruption.

The bottom line is that teams will not feel truly empowered until they realize that the ScrumMaster is serious about the ScrumMaster role. This is most of the battle (and the toughest part of the battle, requiring a ScrumMaster that “gets it”). Until this commitment by the ScrumMaster is proven to the team, teams will rarely understand the nature of a "commitment driven sprint" themselves, and backlog items will continue to slide from sprint to sprint.

The Right Skill Set, the Right Mind Set, The Right ScrumMaster

By Benoît Houle

Over the past several months, we have learned the importance of having the right person in place as the ScrumMaster. Can a ScrumMaster make or break a sprint or a release? Definitely! That’s why it’s important to choose a ScrumMaster who not only has the right skill set, but the right mind set as well.

Here are the attributes and skills we are looking for at BioWare when we hire and evaluate our ScrumMasters:

Attributes (natural but can be developed)

Focused and meticulous

• Ensures that the team’s actions are always aligned with the acceptance criteria and project goals (vision);
• Minimizes errors by taking an organized approach to work assignments.

Team player

• Does not shy away of any tasks that could help the team and leads by example (e.g., if the team decides to work extra hours to meet the sprint goals, the ScrumMaster should be there with them).

Great problem solving ability

• Go-getter who rapidly obtains information to solve problems
• Helps the team identify conflicting priorities, then frames and escalates issues that cannot be resolved quickly.

Trustworthy

• Reliable and walks the talk (executes on what they say every time)

Accessible

• Easy going personality and personable

Skills (learned and experienced)

Outstanding communication and decision making skills

• Propagates information promptly, clearly, and unambiguously
• Knows when to make the call on a decision; no analysis
• Identifies trade-offs between short and long term and promptly reaches a shared vision between the team and product owner

A capacity to make the team work together

• Ability to develop and foster teamwork. Able to diagnose, understand, and facilitate team dynamics.
• Consistently gauges how the team is doing and drives the necessary actions to

  improve.

Inspires and motivates

• Facilitates team mechanics and energizes the people. Motivates, draws out, and rewards the best work from individuals on their team. Highlights exemplary behavior, skills, or accomplishments.
• Great working attitude. Always looks for ways to make changes work rather than only identifying why changes can’t be done.

Emotionally stable and works well in stressful situations

• Stays calm and composed under stress.

Conflict resolution

• Facilitates constructive debate to enable better decisions and shared vision
• Resolves disagreements and conflicts constructively. Knows when to involve others.
• Demonstrates emotional maturity (discretion, objectivity, integrity, confidentiality) in all interactions.
• Supports decisions that have been made, even when he/she does not personally agree.

While choosing the best ScrumMaster is critical, remember that it’s also very important to create the right working environment for the ScrumMaster to succeed: they need to be able to make decisions "stick" and they need to have the authority to remove roadblocks.

The attributes and skills listed here can be a good starting point for creating a list specific to your own company’s unique needs. Choosing the right ScrumMaster is well worth the upfront effort.

Successful Sprint Reviews: The Greatest Story Never Told

By Bob Schatz

Many of us in the agile community hold a number of things sacred when we are helping others adopt Scrum successfully. I have many of them as I see the intrinsic value of each part as a key to the whole. One of these critical parts is the sprint review. As Ken Schwaber has written previously, “The sprint review is not a presentation, as we have come to know them, nor is it a time of judgment. Some of this is simply learned behavior from our past lives in dreaded project reviews. The applause that we hear is a human reaction of approval.” I have heard this applause in early sprint reviews for new teams—a sense of shock and awe at seeing working software so early.

I have observed and participated in a great number of sprint reviews. I’ve seen some quirky things from the Scrum teams as they attempt to demonstrate the working software and artifacts they have produced in the sprint. Most of them squirm and struggle in the art of telling a story. It’s hard to break the habit of thinking only of the technology and step into the world of the person who will live with the system we build.

An Early Death

We often talk about user stories and use cases in the development of the product backlog items. We want to express features and functions in terms of the end user or system component. We also want to include a statement of a feature’s value. These elements provide the context for the technology and help bridge the communication gap between the developers and the users. These stories help everyone collaborate and discuss the experience that the software needs to provide for the person or persons interacting with it. Unfortunately, in many cases, the story dies once it is implemented, and that makes me sad.

A feature’s implementation is not the end of the story but its birth. Once a story is born it should live for the rest of the project. Its birth is the result of collaboration between the developers and the users in the backlog. It drives discussions through the development of the feature in sprint planning, proves itself as reflected in the acceptance tests, and should spring into action in the sprint review. The story can live on through the operation and maintenance of the system, giving the software a grand purpose in world.

The primary purpose of the sprint review is to demonstrate what has come to life as a result of the collaboration of ideas, to gain a common understanding, and to collect valuable feedback so we can adapt and build better software. Any other purpose is secondary and of lower value to the process. Sure, we can use it to prove how talented our Scrum teams are, to show that we can manage ourselves, to show that we can produce parts of the system early, and prove just how complex the problem we are solving is; but that is not why we do this. It is not a show that needs to be produced.

Breathe Life into Your Sprint Review

The one sure fire way to have a good sprint review is to tell a story. You develop the theme in sprint planning by stringing together backlog items and weaving a plot with the user stories. Then you implement these features, testing them based on the story. Next, you bring that story to the sprint review, giving life to the software. Use real characters and locations; make connections with people and the value that the software provides. A well-developed story will stick with people long after the sprint review.

A good sprint review story has the following components:

• A meaningful; relevant theme;
  
• A sequence of events as the user would experience them;
  
• Characters and data that is realistic—use examples and names from your user community or members of the development team;
  
• Is compelling to the people attending the review;
  
• Is relevant to the people in the review; and
  
• Is at an appropriate technical level for attendees.
  

Then we have to practice as teams to learn how to deliver these stories. Oh, you can just use the excuse that we’re all introverts, but we know this is just nonsense. We all tell stories; it’s one of the oldest forms of communications among humans worldwide. If we’re not engaged in telling the story, then why should we expect anyone else to be interested?

A Tale of Two Sprint Reviews

Here is an example to illustrate the difference between letting a story die and giving it life.

Imagine we have three Scrum teams working on a product release. Each of the teams is focused on a specific functional area of the product. For our example, we’ll use a property management system. Here are a few features that you might see on each team’s backlog:

Asset ManagementThe asset accountant should be able to create an asset record for any capital asset.The asset accountant should be able to settle costs to assets under construction.The asset accountant should be able to depreciate any asset that has been received and capitalized.

Equipment ManagementThe equipment manager should be able to create an equipment master record for any capital or non-capital asset.The system should automatically create an asset record for any capital asset.The equipment manager should be able to loan or lease equipment to other business areas.A user should be able to search for unwanted equipment to find items for re-use.

Equipment DisposalThe equipment disposal manager should be notified of all items ready for disposal.The equipment disposal manager should be able to determine if special handling is required for any item ready for disposal.The equipment disposal manager should be able to tag the item with a valid disposal method.

At the sprint review each team demonstrates the functionality they build going through the backlog items. The team describes each of the features. The users provide feedback on the pieces, which is great, but something is missing.

Now imagine that the three teams have collaborated from the beginning of the sprint and have created a theme for the sprint. Each team is working on a piece of the theme, but all are working toward a living scenario. They think about the types of users they are building software for. They consider who will be involved in the sprint reviews and they begin to write acceptance tests which use actual users’ names, office locations, and real assets that they deal with everyday. Nothing engages users more in a sprint review than seeing their own name, their office, and real world items in the demonstration.

This sprint review begins by the team telling a story as they move through the software features:

Welcome to the Sprint 4 Review. Today we are going to tell you about the day in the life of a critical asset, the Pneumatic Schwaberstopper, in our business.

The Bushwood project places an order for a large, custom-built Pneumatic Schwaberstopper to support the project’s goal to increase production output by 20 percent.  Joan Snow, the equipment manager from the Chicago office, logs into the system and chooses to create an equipment record in order to track the asset under construction.  Since Joan indicates that this item is to be capitalized, the system automatically creates a corresponding asset record for financial purposes.

As Acme Industrial Supply, the equipment contractor, reports monthly on the cost of the asset, Ted Casey, the asset accountant from New York, records these costs and settles them to the asset under construction account. The asset is delivered and the project team in Houston uses it for several years.  Later, Ryan Jessup, the equipment manager in Houston, loans the asset to another area of the business.

After another year passes, the asset is no longer needed. Ryan indicates that the asset is ready for disposal and the system notifies Amy Templeton, the equipment disposal manager. Ted Casey, the asset accountant, then completes the process of fully depreciating the asset. Amy then determines that no special handling is required and tags the item for sale at auction.

Can you imagine how much more compelling a sprint review would be with a little storytelling? Can you visualize how well the story would demonstrate the true intent and functionality of the new features?

Tell Your Story

The team should find creative ways to tell the story and demonstrate the interaction and experience with the system. What’s a key word in that sentence? Creative. Have fun with the sprint review; be enthusiastic and interested in what you’ve done. When you tell the story, try to be animated. Use gestures, hands, inflection and change of cadence in your voice and facial expressions. These elements are what bring people into your story and make them feel a part of it. This opens their minds to the reality of what they are seeing and bingo! the quality and quantity of feedback increases.

So, if you’re not getting the most of your sprint reviews don’t blame the users, stakeholders, or product owners. Get your story straight!

Post-It Revisited

By Aaron Conoly

A while ago I wrote about my experiences with Scrum and a little helper I like to call “Posty the Post-It note.” Ok, so I don’t actually call it that, but I do use the Post-It extensively when I’m scrumming.

So how has the Post-it fared in the months following my article? I’ll briefly review what has and hasn’t been working and what we’ve been doing to improve our Post-it power.

Post-it Board
The Post-it board has grown, so much so that it now consists of a 4’ x 6’ white board and a 12’ poster board. So the good news is we’re busy. The bad news is that we are often overwhelmed with the amount of upkeep the Post-it board demands. Ironically the tool we were using to help us get a handle on our workload has now increased it. Sadly, the Post-it board is no longer a place for bragging rights or high-fiving. Now it’s a constant reminder of what I’ve lovingly deemed the “pile.” However, all is not lost. After some discussions with the boss, I’ve convinced the team to only use the board for a few larger projects and to track the smaller projects through other means. We’re still practicing Scrum, but we’re working to minimize the psychological impact of our pile of Post-its.

Lesson learned: If you’re not careful, the Post-it can overwhelm you with its 20,000 friends. Manage your Post-its, and if you’re feeling besieged by bright colored paper, take a deep breath and repeat this mantra, “I’m in control, not the Post-it. You’re not the boss of me, Post-it!”

Post-it Shield
Recently, we added a dedicated ScrumMaster to our team. Essentially, he’s our department’s linebacker. No more outside distractions; if you want to get to one of our Team members, you have to go through him. So every Team member’s cube features a bright orange Post-it that reads, “NEED SOMETHING? GO SEE CHRIS!” It’s not the most subtle method, but it’s helped to drive the point home and allowed our ScrumMaster to run proper interference.

Lessons Learned: My favorite element of Scrum is the ScrumMaster. The ScrumMaster protects the Team (pretty neat, huh?), but they can’t do it alone. We use Post-its to help spread the word and shepherd people to our linebacker.

Name Tags
In theory, placing an “Oink, I’m a Pig” or “Cluck, I’m a Chicken” nametag on your colleagues is a great idea. In practice, it can have unintended consequences and result in hurt feelings. While these name tags helped to spur discussion about Scrum, they were discontinued shortly after an unfortunate incident involving a Team member telling a manager, “Hey chicken! No talking during the Daily Scrum!”

Lessons Learned: It’s important to know your role. It’s also important to continually educate coworkers on the merits of the Daily Scrum and other Scrum practices. Just remember that Scrum can be jarring for your colleagues and to be patient while you walk them through the process.

Are Post-its a regular part of your Scrum routine? If so, how?

Being an Effective Product Owner

By Roman Pichler

When I met Paul, a first-time product owner on a new project, the first thing he asked me was, “What do I really have to do and how much time will it require?” Even though Paul had attended a Scrum introduction a few weeks back, he wanted to double check his responsibilities. He was worried about the time commitment he had to make and the support he would get from his boss.

Helping product owners like Paul getting started is rather the norm for me. In most organizations that I have worked with, product owners are strapped for time, are often not aware of their responsibilities, and are unsure how they should best transition into their new role. Sadly, I have also met many product owners on Scrum projects who resembled more a business sponsor briefly stopping by at the sprint planning and review meeting or an on-site customer interacting more frequently with the team but leaving it to the ScrumMaster to guide the team.

So what is the product owner in Scrum supposed to do? The product owner is required to closely collaborate with the team on an ongoing basis and to guide and direct the team (e.g., by actively managing the product backlog, answering questions when they arise, providing feedback, and signing off work results.) In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out. I have experienced that having a strong, empowered, and present product owner is a key success factor for Scrum projects – just like a strong, empowered team is. Most projects I have come across that had product owners who were not properly available or empowered suffered, and the projects never reached their maximum velocity.

I have found three things particularly helpful for product owners: a thorough understanding of the customer needs, an active stakeholder management, and a basic knowledge of how software is developed and deployed.

Thoroughly understanding the customer needs and how the product will satisfy those needs allows the product owner to describe, prioritizes, and communicate the requirements that really matter and answer all related questions. The product owner should express what value-added is from a customer perspectives and focus the development efforts toward providing that value.

Proactive stakeholder management is particularly important in larger organizations, where the stakeholders include not only customers but also internal functions, such as production support, service or sales, as well. Taking into account and prioritizing the various interests early on and involving stakeholders regularly, for instance in form of user story writing workshops and sprint reviews, is crucial to ensuring that the software can successfully work in its target environment.

Knowing (at least roughly) how good software is developed makes it easier for the product owner to closely communicate with the team. This kind of knowledge helps product owners to better understand how the team works and how important quality and the related agile technical practices are to sustain a high velocity across releases.

This broad skill set implies that ideally, the product owner would be a hybrid: someone who is able to look outward, understanding the end customer needs, and someone who looks inward, managing the value stream that transforms the customer needs into software ready to be used by the customer. Toyota’s Chief Engineer role very much resembles such a hybrid product owner: The Chief Engineer gathers end user requirements, manages the development project, and even makes high-level design decisions. Additionally, the Chief Engineer is a high profile role and has executive support. Does this sound too good to be true? Not so: Toyota has successfully employed the role since the 1950s.

So what did I tell new product owner Paul? Well, I took him through the key activities a product owner has to perform on a Scrum project, from hosting estimation workshops and prepping for the sprint planning meeting to giving feedback to the team and accepting or rejecting work results in the sprint review meeting. I recommended that he free up most of his schedule and defer most of his other commitments to have enough time available. We scheduled the first user story writing workshop with the team and stakeholders, and we set up the first effort estimation workshop. I also volunteered to talk to his manager about Scrum and to explain why it is so important for a product owner to spend enough time with the team every day and to be able to make decisions on the spot.

Being an effective product owner is not easy – nor is being a good ScrumMaster. To get started, be aware of the core responsibilities the product owner has and make sure that the product owner firmly sits in the driver’s seat – all the time.

Am I, or Am I Not, Using Scrum? That is the Question

By Melanie Silver

Agile methodologies, processes, tools, and techniques are not new to software or product development. They have been around for many years. However, as companies start seeing an increased need to improve their time to market while maintaining quality, they are looking to adopt some of these agile techniques in favor over the traditional waterfall methods. Projects in many organizations are claiming to be using agile. They may be using XP (eXtreme Programming), AD (Agile Database Techniques), AM (Agile Modeling), or any number of other agile methods. They may also be using Scrum. The question being addressed here is whether, in fact, projects are using Scrum, or picking and choosing some of the techniques and calling it Scrum.

What is Scrum?

First, let’s look at what Scrum is. According to the Agile Alliance, Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Scrum does not dictate which engineering practices must be used. However, often times you will see it combined with XP to generate the benefits of agile development with the advantages of simple implementations. Scrum, used properly, significantly increases productivity and reduces time to market while facilitating adaptive, empirical systems development.

Scrum adheres to the values as defined in the Agile Manifesto:

“Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan.”

In addition, Scrum principles are the same principles embraced by the Agile Manifesto:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Working software is the primary measure of progress.

Scrum also has its own characteristics and practices:

• Three basic roles: Product Owner, ScrumMaster, and Project Team
• Product Backlog
• Sprint Backlog
• Sprint Planning Meeting
• Daily Scrum Meeting
• Thirty-day iterations, delivering increments of potentially shippable functionality at the end of each iteration
• Sprint Reviews
• Retrospectives

Remember, I stated earlier that Scrum uses an adaptive, empirical process for systems development. This approach demands flexibility and adaptability. Each project is different; that is why this adaptive, empirical approach can adapt to each project’s needs and provide for increased productivity and reduced time to market.

What Isn’t Scrum?

So, to the question of whether a project is, or is not, using Scrum. Let’s look at a few situations:

Scenario One:

The project decides to use Scrum to manage a software development project. Management gives approval to use Scrum but insists that the team follow the prescribed software development processes to ensure the team is doing what they are supposed to be doing.

Scenario Two:

The project decides to use Scrum to manage a non-software development project. The team is not collocated and the Product Owner doesn’t have time to prioritize the Product Backlog. The Product Owner indicates everything is top priority.

Scenario Three:

The project decides to use Scrum to manage a software development project. However, the team decides it doesn’t have time to conduct the retrospectives at the end of each iteration. They also decide to conduct the daily Scrum meeting only twice a week.

I could go on an on about project teams having to follow certain practices that are contrary to Scrum/agile methods, or skipping certain practices, or not adopting the characteristics inherent to Scrum teams. The question some are asking, are those projects still using Scrum? Is it smart to use only some of the Scrum techniques and not others? Employing and adhering to all of the techniques and characteristics of Scrum provides the synergy necessary to produce optimal results. Why would you want to settle for less?

Abandoning some of the practices that make Scrum successful gives the naysayer more opportunities to claim Scrum doesn’t work. One would have been much better off espousing the individual techniques that were used than claiming that the Scrum methodology was applied.

Using only certain Scrum techniques and adopting only some of the Scrum characteristics may not preclude you from claiming you are agile. However, I would use this analogy to show why you cannot profess to be using true Scrum: Can you say you've made a batch of chocolate chip cookies if you leave out the chocolate chips?

Leader of the Band: Six Attributes of a Good ScrumMaster

By Mike Cohn

In my last column I asserted that in an ideal world a team would select its own ScrumMaster, but that it isn’t always practical. I promised that my next column would discuss what to look for in a potential ScrumMaster, whether the selection is being made by the team itself or by someone outside the team. In this week’s column, I present six attributes that your next ScrumMaster should demonstrate.

Responsible

In most organizations, when someone is given responsibility they are concurrently given the authority necessary for success. ScrumMasters are in a different situation. While a ScrumMaster does not assume responsibility for the success of the project—that remains with the team—a ScrumMaster does assume responsibility for the team’s adoption of Scrum and practice of it. A ScrumMaster takes on this responsibility without assuming any of the power that might be useful in achieving in it.

A ScrumMaster’s role is similar to that of an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone. Boston Pops conductor Keith Lockhart has said of his role, “People assume that when you become a conductor you’re into some sort of a Napoleonic thing—that you want to stand on that big box and wield your power. I’m not a power junkie, I’m a responsibility junkie.” In an identical manner, a good ScrumMaster thrives on responsibility—that special type of responsibility that comes without power.

Humble

A good ScrumMaster is not in it for ego. A good ScrumMaster will take pride (often immense pride) in her achievements but the feeling will be “Look what I helped accomplish” rather than the more self-centered “Look what I accomplished.” A humble ScrumMaster is one who realizes the job does not come with a company car or parking spot near the building entrance. Rather than putting his own needs first, a humble ScrumMaster is willing to do whatever is necessary to help the team achieve its goal. Humble ScrumMasters recognize the value in all team members and by example lead others to the same opinion.

Collaborative

A good ScrumMaster will work to ensure a collaborative culture exists within the team. The ScrumMaster needs to make sure team members feel able to raise issues for open discussion and that they feel supported in doing so. The ScrumMaster should help create a collaborative atmosphere for the team through his words and actions. However, beyond modeling a collaborative attitude, a good ScrumMaster will establish collaboration as the team norm and will call out inappropriate behavior (if not already done by other team members).

Committed

While the ScrumMaster role does not always require a full-time, eight-hour-a-day commitment, it does require someone in the role who is fully committed to it. The ScrumMaster must feel the same high level of commitment to the project and the goals of the current sprint as do team members.

A ScrumMaster should not end very many days with impediments raised by the team that are left unaddressed. A team’s impediment list cannot be swept clean by the end of every day because some impediments take time to remove. For example, convincing a manager to dedicate a full-time resource to the team may take a series of discussions with some time between them.

While the ScrumMaster may not be a full-time job, the ScrumMaster should plan on being the ScrumMaster for the full duration of the project. It is very disruptive for a team to change ScrumMasters in midstream.

Influential

To be successful a ScrumMaster will need to influence others both on the team and outside it. Initially, team members may need to be influenced to give Scrum a fair trial or to behave more collaboratively; later a ScrumMaster may influence a team to try new technical practices such as Test-Driven Development or pair programming. A ScrumMaster should know how to exert influence without resorting to a command-and-control “because I say so” style.

Most ScrumMasters will also be called upon to influence those outside the team. A traditional team may need to be convinced to provide a partial implementation to the Scrum team, a QA director may need to be influenced to dedicate full-time testers to the project, or a vice president may need to be convinced to try Scrum at all.

While all ScrumMasters should know how to use their personal influence, the ideal ScrumMaster will come with a degree of corporate political skill. Corporate politics is often used pejoratively; however, a ScrumMaster who knows how decisions are made in the organization, who makes them, which coalitions exist, and so on can be an asset to a team

Knowledgeable

The best ScrumMasters have the technical, market, or specific knowledge to help the team in pursuit of its goal. LaFasto and Larson have studied successful teams and their leaders and have concluded that “an intimate and detailed knowledge of how something works increases the chance of the leader helping the team surface the more subtle technical issues that must be addressed.”