3 More Questions to Ask During Stand-ups

Most everyone is familiar with the three traditional Scrum questions answered during the daily stand-up as presented in the 2016 Scrum Guide by Sutherland and Schwaber:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The purpose of the daily stand-up is for the Development Team to review the previous day's plan and then arrive at a plan for the next 24-hours. In most cases, the Development Team can do this pretty well. The daily stand-up is a straight forward and simple meeting that focuses on the sprint goal but what could be done different to enhance the team's daily goals and daily commitments, commitments which the Development Team will hold themselves accountable for.
To help focus the Development Team on the day's planned delivered value, "What will I do today to help the Development Team meet the Sprint Goal?", it is helpful to expand this into 3 questions before taking about today's plan:

2.1 What is the customer value you'll deliver at the end of today?

2.2 Is there something you can show the Product Owner today?

2.3 Is there something you can do to help get the most important story done today?

Now these three questions are not simply the fantasy of the Scrum Master but are arrived at jointly with the Development Team. Each of the above questions have their roots in team retrospectives and, in the beginning, the team wanted the Scrum Master to ask them. It's very important that the team agree to any enhancements to the daily stand-up. For teams still early in their Agile journey, these questions will probably not seem unreasonable. However, for more mature Agile teams, there definitely needs to be a strong motivation to adopt them. In my particular circumstances, the Scrum Team was very mature and each of these 3 questions addressed a very specific problem the team recognized.

2.1.  What is the customer value you'll deliver at the end of today?

When the question is asked, the team provides an answer in terms of acceptance criteria/tests that would pass at the end of the day that currently fail.
I started asking this question of the Development Team several years ago when it was brought up during a retrospective that during the daily stand-up, the team was focusing on the technical aspects of the work more than the customer problem they were actually meant to be solving. It wasn't that the technical stuff wasn't important, it is, but we wanted the team to keep some focus on what why and who they're doing the work for. During the retrospective, the Product Owner said he was unclear of the progress of the user story, specifically the progress of the user story from a value perspective. More focus on the acceptance criteria and tests was a natural way to convey progress on value completed. The Product Owner was happy and the Development Team added the acceptance tests results as part of their daily planning.
This question provides an additional opportunity to further communications and collaboration between the Development Team and Product Owner. This is achieved by tying the customer, the acceptance criteria, and the solution together as a daily goal, a measure of value delivered each day.

2.2.  Is there something you can show the Product Owner today?

This question sprang from the Developments Team's observation that some work was being rejected by the Product Owner, especially user interface work, too late in the sprint to correct it. The problem was the team was waiting until the story was complete before showing it to the Product Owner. This usually resulted in a new user story being written and added for the next sprint.
During the retrospective, the team recognized that some user stories and the intended value were being missed during the sprint because of the delay in showing progress to the Product Owner. The Development Team and Product Owner quickly saw that viewing incremental progress was the answer but the Development Team needed to alter how they broke down the work into tasks to facilitate this. It was breaking down the work differently that was the real challenge for the team as it required some work to be done that would ultimately be thrown away. This was the occasional stub or driver code to get some display components looking 'right'.
This question provides an excellent opportunity to further collaboration between the Development Team and Product Owner. It serves to help focus on what 'done' means for a particular user story and helps reduce rework through a more collaborative approach to solving a problem. It can also make for a better product faster as the Development Team and Product Owner make any adjustments as a story progresses.

2.3.  Is there something you can do to help get the most important story done today?

This question got its start while 4 teams were working the same backlog and it was observed that new stories were being started while higher priority stories were still in progress sometimes with a large number of tasks in 'To Do'. Although this question came from a Large-Scale Scrum (LeSS) implementation, it scales down nicely to a single team working a single product backlog.
What the Development Team was trying to improve during a retrospective was their ability to swarm until done. When I was developing, I would prefer to work it alone, without outside help whether I could use it or not. The Development Team saw that this mindset tended to slow down getting stuff done and suggested that the question be asked during the stand-up to heighten awareness that getting to 'done' was important. The way it eventuated was tasks still in 'To Do' for the higher priority stories were picked up. It also helped in identifying tasks that needed further breaking down.
The question provided additional visibility to getting stuff done rather than getting stuff in progress. Getting work done quicker gives the Product Owner maximum flexibility in releasing or A/B testing of new features. Unfortunately, companies sometimes look at 6 developers and wonder out loud why there aren't 6 stories in progress.

Outcomes

After having the Scrum Master ask the 3 additional questions at the start, the Development Team began using the questions in context to their plan for the day and the questions themselves weren't asked after a time. These 3 questions helped the team find the deeper meaning to the question, "What will I do today to help the Development Team meet the Sprint Goal?"

Please drop me a line and let me know what you think and your results if you give this a try.

Tweet

New Scrum Master: Problems to solve in your first days

In the previous two posts. First day as Scrum Master and Second day as Scrum Master, I talked about you as a new Scrum Master to a team and some steps you can take to ease yourself into the team's world. The first post talked about a group meeting with all team members including Product Owner. That meeting set up some introductions and gave you some clues as to how the team interacts and possibly some team dynamics. You followed that up with some one-on-one talks with each member of the team. In this post I'll talk about interpreting the results of your one-on-one discussions with the team members.

Once you've finished your talks with the team it's time to pull all the information together and begin planning your actions. The problems mentioned by the Product Owner, developers, testers, BA's, UXD, and others on the team will likely fall into several categories. What's listed below can be used as a guide but doesn't take the place of your own analysis based on your unique set of circumstances.

Team's ability to self-organize and be cross-functional

One Team, One Goal.

This will be by far the most common area of weakness based on the many discussions I've had.  The clue to this will be problems brought up by the team that they can clearly solve themselves but they'll need your help. Some comments might include:

• "Requirements are poorly written",
• "Working on things before we know what to do e.g. UX Designs incomplete",
• "Too many hand-offs", and
• "Definition of Ready and Definition of Done missing".

I'll look into the first comment, "Requirements are poorly written" in some detail. When the Scrum Development Team say this, I'm thinking there's both a communication issue and possibly some role based barriers in place. The comment given by the Development Team makes me think they're not feeling completely responsible for making sure the user stories are backed with heaps of conversation. Both communication and not feeling it's their job can be resolved through well facilitated grooming sessions. The team can become better at self-organizing by tackling head-on the issue of shared understanding of the customer problem documented in user stories. The team can also build their cross-functional capabilities through greater contributions to the user story including the acceptance criteria. For a developer whose experience may be waterfall and where the sole contribution of the developer was code, helping to write the requirements can be a new and possibly frightening turn of events. You as Scrum Master are there to help facilitate this transformation.

Business or company culture as impediments

We do it that way because that's the way we do it.

Problems or issues cited by the team that fall into this category might include:

• "Too many sign-offs and approvals (Designs)",
• "Little interaction between test and other departments",
• "Business emergencies and no way to stop them", and
• "Fixed end date regardless of start date"

It's clear the company culture is not controlled by the development team but they can have an influence. The comments above could make you think the company is a top down Command & Control shop and you'd be right. One thing I've seen in this kind of environment is nothing is written down, it's all done based on memories of past practices. One way to begin affecting this culture is to document how current work is done paying specific attention to the time it all takes. The Scrum Master and team can do this documenting of existing process and then present an alternative process with the now documented benefits and savings. As Scrum Master, you should also seek out and secure executive support or at least, a powerful mid-level manager who can support change. Without support, you're chances of success are severely limited as I've recently learned first hand.

Technical challenges or knowledge gaps that are impediments

Thomas Edison - Incandescent light bulb

This is something I usually note as a result of listening to the development team but it's rare that the team will directly say something with the exception of how testing is done. What I commonly see is a team hampered due to:

• Specialist on team that can't assist in other technical areas
• Test treated as a separate group or sub-team
• Testing always done at the end of sprint

These fall under a team being cross-functional but to get there will require specific training and strong guidance from the Scrum Master.  I once had a team with one tester doing all the testing. I suggested that the developers help out with the testing to speed it up and relieve the pressure on the sole tester. Luckily there wasn't a rope handy as I'm sure the developers would have hung me then and there for speaking such blasphemy. One developer suggested to the managers that they needed to hire more testers. The managers, GM of Product and GM of R&D both told the developers that hiring wasn't an option and that they would need to better support test. Once the management support was established, I was able to help get the developers to run acceptance and system tests. Baby steps. It was the opening needed to begin the longer term goal of spreading a little knowledge throughout the development team. When I left that company, the Scrum Teams did all the UX, testing, and infrastructure work themselves whereas in the beginning, each of these areas had specialist teams doing this work.

How this helps

After my first days and weeks with the team, I continued doing one-on-one talks with all the developers and Product Owners, noting what changes they felt had occurred in the previous month or two, how exactly these changes affected them, what further changes they wanted to see, and what makes them happy to come to work. I often find myself listening to the team chatter but asking the team to tell me their struggles and their delights helps me focus better on serving them. That's my role as Scrum Master, to serve the team.

I welcome your thoughts and comments.

Tweet

Second day as Scrum Master

In the first post of this series, First day as Scrum Master, I talked a little about he first day with your new team. In this post I want to talk about conducting your first one-on-ones with the team members.

After your first day or so with your new team, it's time to get intimate and personal through one-on-one discussions - I don't call them interviews because I want an informal atmosphere for a discussion and not one where people feel they're playing a role.

I use one-on-one to gain insight into the team members world in a non-threatening way. This is a three step process, setting up an one-on-one, conducting the one-on-one, and making sense of the results. For the team members, this process generally gives them a chance to voice their concerns and issues but it almost always leaves them with a sense that someone cares. For you as a Scrum Master, you do care but it's important the team gets the idea that you are there to serve them, that you actually care more about them than yourself.

Setting up the one-on-one

To get started I approach each of the team members and simply ask if I could have 30 minutes of their time to talk about what's working and what isn't from their unique point of view. This establishes a few things:

1) I value their time by setting a time limit,
2) I value their opinion because I want it from their point of view, and
3) I hold out hope and optimism that I might be improving their personal situation.

Most often the person will give me their time right then but if they're too busy, I don't press too hard but ask when would be a better time and suggest a time. This gives them lots of space in case there's apprehension but also lets them know I'm respectful to their time.

For the one-on-one session, select a neutral, non-threatening, private, and casual space. You should avoid meeting rooms if you can as these are usually sterile and a bit too formal for your purposes. At one company they had a room with sofas where I did these and it provided a very relaxed atmosphere.

Conduct the one-on-one

I open the discussion with a promise of non-attribution and ask if it's ok for me to take notes. If you can do this without notes that's better. I have a standard set of questions that ask, worded appropriately for the context. I ask these specifically in this order starting with what are their expectations of me followed by things that might be slowing them or the team down. I finish with a very personal question that almost always is a surprise to the team member. Examples of these are:

1. Why do you think I am coaching your team?
2. What difference do you hope I'll make?
3. What do you want to learn from me?
4. What outside influences hold the team back?
5. What internal barriers/impediments hold the team back?
6. What can we continue doing or do more of to make life on the team better?
7. How can we work more effectively?
8. Why did you come to work this morning?

The first question is important as it sets up all the followup questions but it also sets the tone. I might specifically say, "My job description says to implement Scrum but I didn't get a strong sense of team's perspective of what that means. Why do you think I'm here?" The tone I'm trying to set is I'm here to learn and not coming in with an agenda.

It's also important that however these questions are put forward, use the exact same structure if not word for word, with each team member. This makes it better and easier to compare and consolidate their responses.

At the end of 30 minutes, conclude the session with a very sincere thank you, repeating the key results and promises to follow up.

Spend a few minutes after the person's left to collect your impressions. Clearly note the issues brought up and what you may have promised to do.

Making sense of the results

Once you've gathered your notes from all discussions with team members, including the Product Owner, begin consolidation and looking for common threads. Use this to help prioritize you contributions for improvements. How to do this with examples will be the topic of my next post coming soon.

Thank you for reading and I welcome your comments and suggestions.

Tweet

First day as Scrum Master

If you've been hired as a Scrum Master, you'll most likely have a vision of the future state of the team based on interview questions. But do you really know what's going on? Here's what I have done to start integrating myself with the team and building my knowledge.

The very first thing to do after you get a brief tour of the place, it always starts with a tour, is have a general meet and greet session with your team. Tell them your story, invite questions, and if appropriate, like the team is new to Scrum, discuss why you're there. This is a light-weight meeting more about introductions than any deep understanding. But, you're not just saying hello, you're watching and listening closely. The team will almost certainly be on their best behavior at this first meeting so the clues of how they interact will be subtle and mostly come from body language. Watch how the others react when someone speaks.

Start by asking each team member in turn what their most recent proudest moment, greatest success, or greatest satisfaction was as a member of the team. As you go, note the introverts and extroverts, the cynics and optimists, and note how many shared the same positive experiences. If everyone shares the same experience as their best then this becomes your target of understanding later, that is, what about that experience pulled the team together. If there are several 'greatest' moments then you'll need to dive into this during the one-on-one meetings with the team after to figure out how each person measures success.

Ask each member in turn what their biggest issue or impediment is. Write this down. Be seen as writing it down. This is important as you need to follow-up. The first question is about past successes but the second question is about the team's future and although not explicitly stated, it's setting the goal of more successes in the future.

On your first day, you're looking to set the tone as an open and honest person, as someone who cares about the team, as someone the team can be open with, and as someone there to help. You can do this following these three steps:

1. Telling your story with some personal details, family, pets, an awkward moment but use caution to not go too far. You want to leave the team yearning to learn more about you, not for them to make final judgments.

2. Ask a question about team successes that helps to reveal team dynamics and ask it of each individual. Listen and watch closer for clues to the team. Be cautious that you're not judging but ask any follow-up questions to draw out the experience they felt.

3. Ask the question of what the team expects or hopes you can do for them. You make it clear that you serve the team. Resist any temptations to "solve" problems here, this is not the setting. Do follow-up on any issues or problems, you need to establish that you're there to actively help.

The next thing to do is conduct a one-on-one interviews but this is another topic.

Have a supremely successful week.

Tweet

Self-Organizing Development Team

Definitions

·        Self-organizing teams are composed of individuals who manage their own work, pick up work based on need, and participate in team decision making.

·        Self-organizing teams must have a common focus, mutual trust, and respect.

By being self-organizing and self-managing, the team brings decision making to the level of the problem. This increases the speed and accuracy of problem solving.

Self-organizing and the Scrum Framework

The Scrum Guide gives the Scrum Master the role of coaching the Development Team in self-organization but doesn't provide insight or guide as how this is accomplished. So …

Tips For Management, Agile Coach, and Scrum Master to organize a team toward self-organization

·       Management (yes, management) must establish any parameters that the scrum team is required to work within. For example, usually only managers can hire and fire people. Otherwise, management should ensure they don’t get in the team’s way. Managers need to support the scrum teams rather than be a distraction.

·       Give a scrum team room enough to fail in order to allow them to succeed. Managers must not ‘step in’ every time they perceive the team is on the wrong track. The team may very well be on the wrong track but there are several inspect & adapt opportunities for the scrum team to correct itself. This is the big reason sprints are short, no more than 30 days, and most often 1 or 2-weeks long. I've seen a development team start a sprint, go down the wrong architectural path, discover it, do a re-design, re-do work they had already done, and still meet the sprint goal. True story. However, the chief architect had chewed his nails down to the knuckle while not saying anything. How proud was the development team after this? Extremely – they were trusted to get the job done and done right.

·       From the start, guide the team to do scrum (scrum guide). Shape the mindset and expectations from the start as this will be harder to influence and change later. Doing scrum by-the-book will not make you good at doing scrum but it will be easier for the team to later learn and adopt the nuances and spirit of scrum. 

·       Help the team become confident in their use of scrum early on. Use examples of how each inspect & adapt meeting can help improve the team’s work and their environment.

·       Remove any misconceptions the team has of scrum. Most teams will perceive that scrum is easy to do but it is actually hard to do scrum right day after day. Anticipate the development team’s reaction to this truth.

·       Use positive reinforcement and build a sense of achievement in the team by helping guide the team to successfully completing their sprints. Do not allow a team to over-commit in their sprint planning meeting based on hope alone. Guide the team to select a sprint goal that is achievable and don’t let ‘hope we’ll get it done’ be the team’s strategy. Hope is not a strategy.

·       Encourage ongoing adherence to scrum and agile practices. Watch for danger signs the team is reverting to older, non-agile ways of thinking and doing. For example, do they want to skip the daily scrum or sprint retrospective. Do they think only one person can do work in a specific area. Are they not forthcoming at meetings.

·       Get the customers and users involved in the process. Customers and users need to be engaged during requirement gathering but most importantly, must be engaged with the scrum team during the sprint review. If the customers or users are consistent no-shows at the sprint review or not showing interest at the sprint results, the development team will more likely lose their sense of purpose and possibly blame agile for their lowered self-worth.

·       Inspect & Adapt over blame. When someone on the team messes up, don’t say “Jane screwed up” or anything like this. I would try and restate it along the lines, “how was it the team allowed this thing to happen and what can the team do to prevent this from happening again?” Encourage the team to re-examine their team processes to see if something needs to change to avoid repetition.  Every effort should be made to make the team, as an entity, the focal point during inspect & adapt meetings and discussions rather than specific individuals. This will help reinforce that the everyone on the team is equally responsible and accountable for the results and outcomes of the team. This is along the “all for one and one for all” philosophy. While it’s important to know someone forgot to get their code, document, etc. reviewed, it’s more important to understand how the team allowed this to happen and to see if there’s something the team can do in the future to prevent it from happening again.

·       Identify team members who hamper or slow down the team’s productivity because of their personal characteristics and practices. Individual personality of team members can be considered more important than skill sets when selecting people for a development team. Work with the team and management to remove people who have difficulties adjusting to agile. This is a hard decision but one that needs to happen quickly; these are not ‘bad’ people but are people who can’t adjust to agile and scrum ways of thinking. Many believe the most productive scrum teams are open, honest, willing to change, and can see the team being greater than the sum of the individual team members. If a person doesn’t have or can’t quickly acquire these characteristics, then they may be an obstacle to self-organization and pose a threat to productivity necessitating their removal.

Tweet

The Scrum Master: Career Path or Career Oblivion

What is the career path for a Scrum Master?

That question was raised recently when I was asking people in the Development department if they thought they'd like to be a Scrum Master and whether they would apply for a Scrum Master role. Of course the question and answer related to their specific company but I've heard the same question asked at Agile meetups and Agile conferences. The short answer [to me] is: there's a clear career path for Scrum Masters. The key to this career path is growth.  Let me explain.

Those of you that work in Development are sometimes isolated from the business. This is not an insurmountable problem but let's be honest, work on products occurs in Development and the business of the company occurs in the sales/marketing offices of the various regions. You could think of Development having the intellectual property of the product, the brain, whereas the regional sales/marketing teams (Americas, Asia, Europe, Australia, Africa) form the heart. Neither can survive without the other and both are necessary for growth and vitality. The best scenario is that the brain (Development) and the heart (sales/marketing teams with their customer insights) work together in a seamless, symbiotic relationship. Establishing and maintaining a great communications link, having everyone working from the same page, and working toward a shared product vision are essential ingredients for growth. From a Scrum prospective, the Scrum Masters are the people whose role it is to find a way to make this happen.

In the Scrum Guide, Ken Schwaber and Jeff Sutherland imagine a world where the Scrum Masters, get the organization to understand and work with the Scrum Teams by:

• Leading and coaching the organization in its Scrum adoption,
• Planning Scrum implementations within the organization,
• Helping employees and stakeholders understand and enact Scrum and empirical product development, and
• Causing change that increases the productivity of the Scrum Team.

A Scrum Master will hasten the adoption of Scrum Values (from the Scrum Alliance) 

• Focus - Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. 
• Courage - Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. 
• Openness - As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.
• Commitment - Because we have great control over our own destiny, we are more committed to success.
• Respect - As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

But how does this lead to a career path?

By improving lines of communications, by getting those in direct contact with customers communicating the pain customers feel, by getting the product development teams to have empathy with the customer, by understanding the impact of technical solutions on the customers, by keeping all aspects of the business informed of customer problems and potential solutions, by being transparent, by continually striving to improve, by creating a culture where learning trumps blame, by creating a culture where the question is not, "what have you done?" but instead, "how can I help you?", by doing all these and more, the Scrum Master will create the opportunity for the company to experience unprecedented growth. And when you have growth, you create more jobs and a larger product base and with that comes the need for more sales people, more marketers, more product managers, more products, more projects, and more Scrum Teams. I should say that Scrum Masters are almost never ever directly responsible for a company's growth. However, through the actions of the Scrum Master and many of the communication improvements and process streamlining, the inevitable result will most likely be growth.

Scrum Masters typically move into roles like product owner, product manager, head product owner, head of product management, program manager, project director, program director, agile coaching, development manager, technology manager, and others. Most of these roles may not exist today but with growth and expansion, some of these roles will come into being.

Whether your company or business has a global footprint or is a young Start-up, Agile and Scrum can be tools for growth and the Scrum Master role is positioned so that the results of good Scrum Mastery is company growth. Once there's growth, there almost always follows more and greater opportunities. Who is better positioned to move up and forward than the Scrum Master?

Your thoughts?

Tweet

Measuring the Success Of The Scrum Master

The Scrum Guide states, "[T]he Scrum Master is responsible for ensuring Scrum is understood and enacted." Scrum is defined in the Scrum Guide as follows: "Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value." So, one could logically conclude that the scrum master role is responsible for ensuring the scrum team is "productively and creatively delivering products of the highest possible value." I think that the CEO, CTO, Development Department Manager will particularly note the "highest possible value" aspect of the scrum master role and want to know if the scrum master is coaching the team toward this goal. Here are a few points to track the success of the scrum master:

• Is the scrum team (development, product owner, and scrum master) following the 12 principles of agile as defined in the agile manifesto?
• Is the scrum master ensuring the scrum team (development, product owner, and scrum master) is following the rules of scrum as defined in the scrum guide?
• Is the scrum master helping those outside the scrum team understand agile and scrum?
• Is the scrum master protecting the development team from interruptions?
• Is the scrum master removing obstacles and problems affecting the scrum team e.g. getting better computers, coffee, baby sitters, listening to problems ...?
• Is the development team moving toward being self-organizing?
• Is the development team moving toward being cross-functional?
• Is the development team enjoying work or do they dread coming to work?

I think most measures for scrum master are subjective but that really means you must exercise greater caution when applying your scientific methods. For example, if the product owner randomly asked ten customers if they liked the user interface to a product and one voiced the opinion that it's bad, then you probably wouldn't change the interface. If however, nine of the ten voiced the opinion that the user interface is bad then this means something even though it's still all very subjective. What the product owner is doing is taking purely subjective measures and objectively applying them to the science of statistics. Could all nine customers be an anomaly with your other 991 customers happy with the user interface? Of course the answer is yes but it's also very unlikely.

 

Measuring the scrum master's performance against the expectations found in the Scrum Guide can follow the same principles as above. For example, measuring the scrum master’s service to the development team in "coaching the Development Team in self-organization", one could use several subjective measures together, with any weighting you choose, and reasonably determine over time if the development team is becoming more, less, or remaining static in self-organizing, assuming the method of measuring and weighting remains constant. These measures might include:

• How does the scrum team rate itself in forming-storming-norming-performing?
• Does the development team pull items from the product backlog rather than having them pushed onto them?
• At the daily scrum, is the development team providing status to the chickens or are they planning the day's work?
• At the daily scrum, does one development team member repeatedly advise others of what work they should be doing?
• At the retrospectives, does the scrum team actively pursue areas for improvement and then execute on these improvements?
• Does the development team often seek outside assist on how to implement a user story?

Enough subjective measures can be found to objectively determine if the development team is self-organizing.

 

What Is Success?

You may often times hear that working software is the measure of a scrum team's success and this is then used to determine the general success of every person in the scrum team, including the scrum master. I would argue that this is not enough since working software doesn't necessarily mean it's valuable. Think about delivering working software after the company had already lost a competitive advantage or delivering working software that no one wanted or bought. It's also conceivable that some customers, early adopters spring to mind, would tolerate software that doesn't completely work in order to see the concepts and the potential of the product. The Scrum Guide specifically allocates responsibilities to the product owner and scrum master with regards to adding value; not so for the development team. I think that "value" in the context of the Scrum Guide is value for the customer and, consequently, for the business. The rules and practices in the Scrum Guide are there to support the 12 agile principles including the very first, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." It's the scrum master's role to ensure that the scrum team "satisf[ies] the customer" through the “continuous delivery of valuable software". The scrum master does this by making sure the scrum team "adheres to Scrum theory, practices, and rules". It's the responsibilities of the scrum master, as defined in the Scrum Guide, that business can use to measure the success and effectiveness of the person given the role of scrum master.

 

 

 

Tweet

Before The First Scrum: The Scrum Master

The role of the Scrum Master is arguably the most important role on the Scrum Team. The 2011 Scrum Guide by Ken Schwaber and Jeff Sutherland define the role of Scrum Master as:

"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practises, and rules. The Scrum Master is a servant-leader for the Scrum Team."

If a Scrum Team is having problems following Scrum practises and rules or is being interrupted and distracted, it's the Scrum Master we hold accountable to correct this. It is imperative that the right person is selected, appointed, or steps into the role of Scrum Master.

Selecting The Scrum Master

The Scrum Master must understand Scrum. This doesn't necessarily mean that the person has committed to memory the Scrum Guide or completed a Certified Scrum Master course but should have an understanding of Scrum that goes beyond these two artifacts. The prospective Scrum Master should have an ingrained knowledge and comprehension of the Agile Manifesto and the twelve principles behind it. The prospective Scrum Master should be committed to following the 5 principal Scrum activities, Sprint Planning, Daily Scrum, Sprint, Sprint Review, and Sprint Retrospective, and the rules of Scrum as outlined in the Scrum Guide.

The Scrum Master is usually selected from within the existing software organization. This may be project managers, team leads, senior software engineers, senior testers, etc. I've listed what seems to be the more experienced personnel of a software organization but I really don't think that a lot of software experience is essential for a Scrum Master. You won't find any technical requirements in the Scrum Guide for the Scrum Master role. In fact, a lot of technical experience could work to the detriment of a Scrum Master. For example, a strong technically minded project manager or team lead is usually an asset in a waterfall, command and control environment but in Scrum, a strong, technically minded Scrum Master may start 'telling' the Development Team how to do their work. The Development Team is meant to be self-organizing and Scrum assumes the people doing the work know best how to do it. From the Scrum Guide: "No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality".

Where I worked, the first Scrum Master came about when the person was asked by management to research the various Agile methodologies but focusing on Scrum, and provide a recommendation on how to best adopt Agile. This exercise really served two purposes: 1) Figure out which Agile methodology best suited the company's current situation (Scrum hands down) and 2) Give the potential Scrum Master a means to obtain a broad understanding of Agile and build a solid knowledge base of the recommended methodology.

Whoever the company or software development organization chooses to be Scrum Master, this person should have the following qualities:

• Be an early adopter,
• Understand, embrace, and be fluent in the Agile Manifesto,
• Be fully conversant in Scrum,
• Be well read on adopting Agile and Scrum,
• Have the stamina and patience to teach Scrum to the organization, and
• Have enormous enthusiasm for all things Scrum.

Be an early adopter: For most organizations, adopting Scrum is or will be a big change from a waterfall methodology. The Scrum Master must believe that Scrum is a better approach to software development. The Scrum Master can help convince the Development Team and software organization that Scrum is a better than waterfall if and only if, the Scrum Master believes this to be true to the core. Suppose a retrospective is skipped because the Development Team couldn't see the value in it two weeks after the last retrospective. If the Scrum Master allows this, the Scrum Master is not convinced a retrospective is needed after every sprint.

Understand, embrace, and be fluent in the Agile Manifesto: This document is the heart of Agile. Customer collaboration, high visibility of work, frequent deliveries, openness and honesty, continuous improvement, face-to-face communications, working software: they're all part of the Agile Manifesto as they are to Scrum.

Be fully conversant in Scrum: The Scrum Master will need to understand the Scrum Guide and it implications. Following the Scrum framework right from the start is essential; anything less will weaken the value of Scrum and can eventually lead back to waterfall. At first, the Scrum Team will probably resist the change to Scrum and will be reluctant to self-organize. What I found was developers new to Scrum are able to go through the mechanics of Scrum but with little appreciation of the benefits of Scrum. A Scrum Master must be able to identify and correct any variances from Scrum immediately.

Be well read on adopting Agile and Scrum: When a Scrum Team first forms, there will be some resistance to change but the Scrum Master can help ease people through it by citing examples of how other organizations got through the various issues the team will face. If the Scrum Master can address the issue and provide possible solutions immediately, the Scrum Team will gain confidence in Scrum and the Scrum Master. Almost any issue a team will face has probably been seen by someone else and they have somewhere documented it on the web. The Scrum Development Group on Yahoo (http://tech.groups.yahoo.com/group/scrumdevelopment/) is an excellent source of information but there are many blogs and other web sources that can be mined for solutions. Or, if you like, you can email me with your issue which I promise to answer quickly. Some areas that will probably cause confusion are:

• User Stories-How to write them and how to estimate them.
• Story Points-How to do relative estimations.
• Acceptance Testing-How to write acceptance criteria and who runs these tests.
• Continuous Integration-How to deliver new/modified capabilities every day.
• Daily Builds-Automating a daily build with automated system, acceptance, integration, and unit testing.
• Daily Scrum- Getting the most out of the meeting in < 15 minutes.
• Technical Debt-How to deal with partially completed stories and bugs.
• Self-Organization-What this means and how to achieve it.
• Development Team Structure-How to deal with former hierarchy and titles in Scrum.

There are many other issues that will pop up but the ones above I've seen in every team new to Scrum.

Have the stamina and patience to teach Scrum to the organization: I think this is the most demanding aspect of the Scrum Master's job.  I was lucky in that my boss was a superb listener and I was able to talk to him and come to better understand some of the issues I was confronted with.

Usually when I had problems with an individual or worst, the whole Development Team, it was paramount to separate the emotion from the logic and facts. I tended to speak a bit slower with carefully chosen words and appeal to the logic of the situation. I once spent over an hour with 2 people trying to explain that failing to meet a commitment (sprint goal) is not the end of the world. The team was unable to complete one of the user stories in the sprint and felt they had failed. My argument was that the complexity of some user stories is not entirely known at the start of the sprint and that the team's velocity, the average amount of work the team can expect to achieve during a sprint, is really a guide of the amount of work the team might achieve. If the team doesn't feel they can meet the goal of the sprint then the goal should be re-negotiated. In this case, the team was unable to see that they weren't going to meet the sprint goal-a common practice of developers I've seen over the years. Like the people on the Titanic, they believed that rescue was only moments away even while the ship was so obviously sinking. Why developers sometimes feel they'll be fired; not yelled at, not take a pay cut, but fired for making an inaccurate estimate is beyond me. In almost 30 years I've never seen the slightest disciplinary action against an individual for making an estimate that proved in fact to be wrong. In any case, after spending over an hour talking about vagaries of software estimates and about using the retrospective to figure out why the team over committed, I went home thinking that I failed to reach these people. You can imagine my surprise and strong emotional response when early the next morning I found an email where one person got it and realized that with Scrum, they can only do what they can do and that over commitment, especially in the early sprints, is something nobody is too upset over and that during their retrospective, the team needs to understand why it over committed  and make the appropriate modifications.

Have enormous enthusiasm for all things Scrum: If you need to pretend to be enthusiastic about Scrum then being a Scrum Master is not for you. I really loved being a Scrum Master. I was genuinely moved when the light turned on for team members as they comprehended the various facets of Scrum. My philosophy was that you initially do Scrum by the book (i.e. Scrum Guide). If something isn't working after you've given a fair chance then solicit from the Scrum Team on what should change. However, after two years doing Scrum, nothing about Scrum changed. Of course there were changes on how user stories were written, how to do acceptance testing, and other technical components but nothing about Scrum actually changed. The Development Team may take a while to make the transition between waterfall and Scrum but the Scrum Master knows Scrum is better and will be constantly pointing out to the team why Scrum is better.

Tweet