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

Documenting Your Best Practices

I think it's important for the software organization to have documented Best Practices to provide a common starting point for all engineers, whether new or well-seasoned. The term Best Practice simply means this is the most efficient or simplest or greatest customer/business value, (I would stress the latter) way of doing something known to date. What Best Practice doesn't mean is that it's a rule. Rules change infrequently but Best Practices are always open to change.

The business may have a rule that an agile team must have a daily stand-up meeting visible and accessible to anyone who wishes to attend given the space available. How an agile team implements the daily stand-up meeting is subject to one or more Best Practice. There may be a Best Practice that has the Scrum Master facilitating this meeting, asking three questions: what have you done, what will you do and what problems are you having. There can be another Best Practice that has a different development team member facilitating the daily stand-up each day in a round robin fashion. Both these Best Practices can exist at the same time, in the same document, until one is proven better or, if they are equally beneficial, one is proven more popular.

I think that Best Practices are potentially updated after each agile teams' retrospective. One major pitfall of documenting Best Practices is these are never reviewed and updated. The business must guard against Best Practices becoming static and agile teams or the development manager need to ensure there's an ongoing effort to review and validate all Best Practices. If the Best Practices document hasn't changed in 30 days then maybe the agile teams are not trying to improve since most Best Practices are used in each sprint and subjected to retrospective review at the end of each sprint. If for example, all agile teams adopted the practice of having the Scrum Master facilitate the daily stand-up, having tried and rejected having a development team member facilitate, I would probably remove the Best Practice of having a different development team member facilitating the daily stand-up.

One last point, I don’t think there’s generally a great amount of detail in Best Practices as these are not always step-by-step procedures, at least not in an agile environment. If there’s a Best Practice to use planning poker in a sprint planning meeting (or grooming session) then there’s probably a brief description of what planning poker is and maybe a link to Wikipedia. Planning poker is a good example since there are at least a dozen different implementations that are almost but not quite the same. However, a code review Best Practice may be very detailed because there’s proven value in your company by following these detailed steps.

 

Best Practices document the way you do things now so you have something to use to measure improvement against. Best Practices become the organizations best training aid for new-hires and is the guide for all. Best Practices change all the time as agile teams experiment and replace outdated practices with new and better practices. Taiichi Ohno of Toyota Lean Manufacturing fame is quoted as saying, "There is something called standard work, but standards should be changed constantly. Instead, if you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen. It is kai-aku [change for the worse] if things get worse than now, and it is kaizen [change for the better] if things get better than now. Standards are set arbitrarily by humans, so how can they not change?" All you need do is replace "standard" with "Best Practice".

 

 

 

Tweet

Retrospectives With Scientific Validation

During retrospectives, agile teams would benefit from following the Lean Startup concept of testing their improvement hypotheses using scientific methods. My experience during agile retrospectives has been that for most 'improvements', there's no deliberate validation that the change actually makes the hoped for improvement. The trick is to select quantifiable measures that can be directly linked to the 'improvement' i.e., cause and effect are firmly linked. In essence, the Scrum team conducts a scientific experiment to determine if for some action/activity/change they get a measurable improvement.

It's important that the team only do one improvement at a time so that any effects can be attributed to the improvement. For example, if you're introducing pair-programming to reduce acceptance tests failures but you've also introduced a new test harness to help increase test coverage, you might find it difficult or impossible to determine which of these two affected acceptance test results and by how much.

The retrospective process steps:

1. Problem Statement: Clearly state the exact problem the improvement will solve
2. Desired Outcome: Clearly state what the results will be with the improvement in place
3. Experiment Summary: Develop the falsifiable* hypothesis for the improvement
4. Measures: Identify the metrics and measures to collect
5. Data Collection: Identify how the metric data are collected. Identify how the collected data is presented
6. Results Validation: Identify how the team will know the hypothesis is proven true beyond a reasonable doubt. Identify how the team will know the hypothesis is proven false beyond a reasonable doubt

The information gathered above is the output of the retrospective. The team should place the falsifiable hypothesis for improvement [retrospective experiment] in a prominent location so everyone in the organization can understand the problem the team hopes to solve, what the experiment is to solve it, and the hoped for results of the improvement.

*A falsifiable hypothesis is a statement that can be proven wrong through observation or experiment. The structure of a falsifiable hypothesis is, "The team will [make this improvement] by [doing/not doing this action or activity]."

Tweet

Development's First Sprint: Things To Improve

There are many concepts of Agile and Scrum that new Development Teams may have trouble with in their first couple of sprints; daily builds not working, acceptance tests not automated, regression tests not automated, and on and on. These problems will pop up and the team will need to deal with them as well as anything else that comes between the team and a quality product they can be proud of. I've listed below some problems that by themselves aren't that big but I think have a long term impact on how well a Development Team becomes self-organized and cross-functional. I believe these are transitional problems that once solved, can help turn a group of individuals into a strong Scrum Development Team. 

Development Team isn't collaborating on designs and task identification.

The last thing a Scrum Master wants to hear at a retrospective is that team members couldn't help one another during the sprint because, "I didn't know anything about ___ ". This, or something like it, will happen in the Development Team's early sprints. The biggest reason for this is not everyone in the Development Team understands the high-level design or knows exactly what the tasks are about. This is usually the result of the walls people have built around technology areas or themselves. This behavior is often seen in a waterfall environment where the individual hero is praised and usually given the greatest rewards. However, the reason you and the company are most likely moving to Agile is to increase productivity, have more frequent releases, have happier customers, and increase profitability. The concept of  individual heroes now becomes a drag on these plans; no one can pick up the work of a hero if that person is sick, on vacation, or wins the lottery and leaves. Heroes also tend not to ask for help if they find themselves in some kind of trouble; that wall they built not only isolates the technology but it also hides mistakes and indecision.  Agile and Scrum welcomes these heroes into a Development Team but asks that they do two things: teach their specialty area to other team members and to learn the specialty areas of other team members. Having a Development Team that can do most any job, even if it takes 3 times longer to do it, will have profound benefits for the Scrum Team, the customers, and the company. A Development Team where everyone can collaborate on the design will result in the best designs. A Development Team that collaborates to find the simplest tasks to accomplish work will maximize the amount of work not done.

The Development Team's collaboration begins with the second part of the sprint planning meeting. This part of the meeting is for the Development Team to start "designing the system and the work needed to convert the Product Backlog into a working product increment." This is meant to be a collaborative effort by the Development Team to identify the work necessary for the first couple of days of the sprint. The Scrum Master should not only ensure this collaboration happens during the sprint planning meeting but should also ensure that the team does this throughout the sprint to identify the designs and tasks needed to complete each story.

Development Team feels estimating is a life and death struggle.

I was once at a sprint planning meeting where one person could not live with an estimation of 8 hours and insisted the 'correct' estimate was 12 hours. This person could not compromise on 9, 10, or even 11 hours: the correct estimate was 12 hours. I'm sure that in every company, every person estimating has experienced this in one form or another. There are going to be people in the Development Team who are afraid of being wrong or insist they're right. There may even be rumours that someone was let go because of poor estimations. Where I worked, this was a commonly stated 'fact' but even the smallest amount of research showed that this never happened; no developer was ever fired simply because they made an estimate that proved wrong. The Scrum Master can limit this by having the Development Team use story points and Planning Poker. Story point are just abstract enough to help the team reach consensus without getting too bogged down in precision. Another technique that can help is the Fist-of-Five for reaching a consensus. Use a 2 or 3 minute egg timer to hold debates over different estimations to a reasonable time limit will also hasten consensus.

The Scrum Master can show that there are no adverse repercussions with estimations by noting the estimates of tasks and stories and comparing the estimates with the actuals (don't attribute names to these). During the sprint retrospective ask the team to explain why some estimates differed from the actuals and let them suggest improvements to estimation techniques. The team will come to recognize that they provided the best estimates they could based on the knowledge they had at the time. However, the Scrum Master must be prepared to answer the inevitable suggestion that the Development Team do prototyping and design before doing story estimates and task breakdowns. The answer to this lies with the estimates Vs actuals. I had found Development Teams estimates are generally around 10% - 20%; a very good showing (the Nokia test has the goal of +/- 10%). It's likely that the Development Team does pretty well on their estimates but may have the occasional anomaly where they're off. Every time team estimates are off by > 50%, they should analyse the possible reasons during the retrospective. All of this analysis is done within the Development Team and isn't something that is made public although lessons learned are often shared with the organization. Outside the Scrum Team there really isn't any indication of estimation accuracy except maybe the team's velocity. However, velocity is an average over several sprints and won't be meaningful for new Development Teams until the 4th, 5th, or even 6th sprint. By this time, the Development Team should be less anxious over their individual estimates.

Tasks should be pooled and not assigned to individuals.

Development Team members may assign or take sprint tasks during planning and not concern themselves with other tasks not assign to them. Prior to adopting Agile, this is the generally accepted behavior but it will get in the way of a Scrum Development Team's being self-organized and cross-functional. The Development Team must exercise collective ownership of all work necessary to complete a story, after all, the team is held accountable to doing the work, not one individual. One thing the Scrum Master can do to help re-enforce accountability and provide cross-functional training is to have the Development Team members take the task from the person on their right and do that task instead of the one they announced during the meeting. This won't be popular with the Scrum Team and it probably won't be too popular with managers attending the daily scrum so don't do this too often; once or twice in each of the early sprints. This will drive home the lesson that there will be times when team members are sick, on vacation, or leave the company and the other members of the team need to step up and do work in areas they're uncomfortable with. In my experience, the discomfort is fear of the unknown rather than being technically incapable of doing the work.

The Scrum Master can also suggest that the Scrum Team do 1 week sprints. This forces the team to concentrate on just a few user stories, generally working on 1 story until it's completed before going on to the next. The Development Team members will often say that there isn't enough work on 1 story to keep everyone busy. My suggestion is for the team to sit down together and lay out all the tasks of a story showing what bits can be done in parallel and which ones have dependencies. This will generally result in a tasks for a story that are smaller and more detailed than the team would have previously done. Following a 'test first' philosophy, for both acceptance tests and unit/integration tests, will allow more people to work a single story and can even get the story completed faster.

Development Team is found skipping peer reviews and testing of software prior to delivery to repository.

This is one of those issues that occurs most often when the team feels pressure (real or perceived) to deliver something, anything by a specified time or date. If the Product Owner or management is exerting undo pressure on the Development Team, creating anxiety, the Scrum Master needs to re-educate them on the rules of Scrum, specifically, "Development Teams are structured and empowered by the organization to organize and manage their own work." It may be very hard or impossible for the Scrum Master to protect the team against excessive management pressure but the Scrum Master must try and convince management that the Development Team deserves the chance to be successful. Finally, if the Scrum Master is exerting pressure then you probably need to find a new Scrum Master, one better informed on Scrum.

I've also seen this problem because the developers are skipping reviews and tests on their own initiative. During a retrospective after a particularly embarrassing delivery to the customer, the Development Team asked that the Scrum Master double check the team's quality controls by asking for each completed task identified in the daily scrum: 1) was the new/modified code peer reviewed, 2) has all new/modified code been unit tested, 3) has the new/modified functionality been system tested, 4) have acceptance tests been run or partially run, and 5) has the product been regression tested in the affected areas. The scope and depth of testing is left to the Development Team's collective common sense. This actually worked well and after a couple of sprints the questions were no longer asked. What was interesting was how the developers reacted to these questions in the daily scrum. At first, some team members were sheepish and I got the impression that sometimes the answers weren't completely true but no one else on the team said anything. After a few more daily scrums with these questions, the other team members would occasionally question a team member's answer. Eventually the team members would question what was done before the Scrum Master could ask a question.

Tweet

Before the First Scrum: Development Team

The members of the new Scrum Development Team are usually drawn from the company's existing software development organization and have probably been following a waterfall methodology until now. If your company's planning on using a Scrum Coach, then most of what follows may not be applicable as the coach with have their own methods and techniques. However, for those organizations that will have their Scrum Teams self-start from within, here are some points on how to select the Development Team and prepare them for their first sprint.

Selecting the Development Team

The Scrum Guide lists the Development Team's characteristics as: self-organizing, cross-functional, having no titles other than Development Team member, equally shared accountability for the sprint, and no sub-teams within the Development Team e.g. database, test, GUI, etc. Although it's possible that your first Development Team will have these characteristics, it's very unlikely. These characteristics are what the Development Team hopes to achieve and it's the Scrum Master that will help guide the team as quickly and with as few detours as possible over the first half dozen sprints or so.

So what is it you're looking for when forming a Scrum Development Team for the first time? There's really only one thing that needs to be considered: the Development Team will need to have the technical expertise to do the work that the project's requirements demand. The company I worked at did exactly this when forming their very first Scrum Development Team and it proved to be a success. A step by step approach to select and prepare a Development Team for Scrum might look like this:

1. Review the project's requirements to determine the necessary functionality and necessary technical competencies needed for implementation. The review is probably done by Product Managers, Project Managers, senior architects, and team leads. The irony is that with the exception of Product Manager, these roles will almost certainly disappear as the software organization moves toward Scrum. The Scrum Team as a unit will replace the team leads, architects and project managers as they become more self-organizing.

My first experience with Scrum started this way. The company was doing waterfall when a new business opportunity came along. Once management, particularly Product Management and R&D Manager understood the requirements, it didn't take long to see that waterfall methods wouldn't be able to meet the contract dates. They concluded that a different development methodology was needed that could quickly implement a few hundred requirements but be transparent enough so unnecessary and problematic requirements could be dropped long before developers wasted a lot of time on them. Agile and Scrum provide the transparency and seemed a logical fit in order to meet the contract.

2. Based on these needs, create a list of 5 - 7 software personnel that will satisfy most or all of the technical competencies needed. Everyone in a development organization should be considered for membership in a Scrum Development Team. The only exception might be someone known to be totally unable to work in a team environment. Even then I would suggest placing these people in a Scrum Team as you might be surprised who fits in and who doesn't. Management should allow everyone a chance to succeed in Agile. Try to avoid putting only the very best software people into a single Scrum Team. It isn't necessary since the total of knowledge in a Scrum Development Team is usually greater than the knowledge of any one individual. And besides, if your company decides it will have 2, 4, or more Scrum Teams, the more experienced people can be seeded to every team rather than all in one team.

My first Scrum Team consisted of the most experienced people (team leads) in the software organization and were selected based on the technical requirements of the project. The project had 4-2 week sprints and was a great success. After the two month project ended, the Scrum Team split up. Although they did the principle Scrum activities; sprint planning, sprint, daily scrum, sprint review, and sprint retrospective, they didn't really do Scrum all that well. In my view, having only the most experienced or senior engineers in one team, the ones who have been doing waterfall the longest, will slow progress toward self-organizing and being cross-functional. These senior people will have to change the most to adopt Agile and Scrum. For example, during a daily scrum meeting it became apparent that one team member wasn't doing any of the tasks on the scrum board in his specialist area. No other Development Team member questioned this. When I asked what task he was doing he said it would take longer to explain what he was doing than to do it. He didn't ask his fellow team members for assistance but neither did any other team members offer to assist. The Scrum Team's team lead called in an architect to help on the problem and after working the weekend, the problem was resolved. In the post project review it turned out that because most everyone on the team was a fairly senior engineer and team leader, they felt that the Scrum Team's team lead would sort it out as they would do if they were the team lead. In the pre-Agile environment, the team lead had the responsibility for solving technical problems for the team and was generally held accountable for the team's success. In Scrum, the accountability for the success of a sprint rests equally among all the team members. This is a significant power shift for former team leads.

On the other hand, getting the more senior software people on board with Scrum through a short-ish project can have long term benefits. Once this team breaks up, they can go to other new teams and be champions of Scrum within their new teams.

3. The Scrum Master introduces Agile and Scrum to the newly formed Development Team. The focus should be the Agile Manifesto and the 12 principles. The Scrum Master should describe the Scrum Roles, the expectations of the Development Team as they relate to Scrum, and emphasize the Development Team's empowerment to find and implement an appropriate solution. I would suggest this be a short introduction; no longer than 60 minutes. Review the Agile Manifesto and Scrum Guide and then tell the Development Team that they're empowered to run the sprint as best they see. Start sprint planning that day or the next.

A short meeting (< 60 minutes) just to present the facts of Agile and Scrum will help the Development Team 'hit the deck running.' If you have a long, drawn out session, the conversation will eventually lead to discussing waterfall  which will invite comparisons between "the way we used to do it" and Scrum. This will lead the team members making choices between the two i.e. which is better. The purpose of this meeting is to familiarize the Development Team on Agile and Scrum and not to debate whether the company should be changing to Agile (I assume those discussions and decisions had already taken place). I suggest going through the Agile Manifesto first and then the Scrum Guide. When doing the Scrum Guide, relate the points in the Scrum Guide back to the Manifesto to help re-enforce the principles of Agile. An agenda might look like this:

1. Agile Manifesto
2. Scrum Roles
3. Scrum Principle Activities
4. Scrum Rules
5. New Techniques And Concepts [user stories, planning poker, acceptance tests, continuous integration, daily builds, ...]

4. Co-locate the Development Team removing any partitions, bookcases, or other office furniture that prevents the newly formed team from being able to make eye contact and hear each other talk. Get some whiteboards or have a wall located with the team where they can track their sprints (Scrum Board), add notes, do designs, document user stories and acceptance criteria, and plan the release. All this will help facilitate communication within the team. The Scrum Master and Product Owner should sit next to the Development Team's area where they can hear snatches of conversation and be summoned quickly but they shouldn't sit with the Development Team. Co-locating the Development Team, will help empower them to self-organize, makes it easier for the team to learn from each other (cross-functional), and fosters direct, face-to-face communications.

A few people, usually the shy or paranoid, will absolutely loath moving but the majority will be able to see the benefits. After a few sprints, the shy people will be noticeably more open and communicative and the paranoid people will be less fearful of their work being scrutinized.  Be sure to have plenty of white board space for the team.

5. Establish a Definition of Done for the Scrum Team (see the short paper Definition of Done: How to Ensure Compliance). The Scrum Master might want to assess the Development Team's capabilities for their first couple of sprints and allow the team to adopt a Definition of Done that offers the team a chance to succeed and yet has room for growth.  As the Scrum Team re-assesses their Definition of Done at each sprint retrospective, any weaknesses in the Definition of Done can be addressed and the Definition of Done modified to strengthen and improve the team's sprint results.

I found that the Scrum Teams had a terrible time adhering to their Definition of Done, especially in their first few sprints. I think the reason for compromising the Definition of Done is due to the long tradition of shipping products even when they weren't ready. The line goes something like; the customer would rather have something that almost works than to have nothing.  In pre-Agile you deliver something that doesn't always work whereas in post-Agile you deliver something that works but may not have all the features. This is a subtle difference but I think it's the key to Agile. The customer is meant to see new and working features and capabilities at each sprint review.

6. The team needs to develop the capability to generate daily builds before starting the first sprint. This phase is often called sprint zero. To take full advantage of Agile, the team needs the ability to generate workable builds on a daily basis.  This is part of continuous integration. Continuous integration is the practice of performing a clean build, conducting full integration, and running all tests every time a change is committed to the code repository. This is accompanied by frequent integration of each developer’s work into the code repository.

Working builds were a luxury during my first sprint but steadily improved during the subsequent sprints. This was a most import lesson learnt in our first venture into Scrum. At a minimum, the team needs to successfully run automated unit/integration tests on a daily basis to help ensure the quality of new code and ensure there's no regression on legacy code. The team needs to have a build notification message, usually emailed, that lets people to know what the build status is and exactly which feature was being delivered or what in a feature was being fixed.  The team should be striving to have acceptance tests automated and run on a daily basis. The team needs to get to the point where it is unacceptable for a build to be broken.  If the build breaks or the product regresses, the offending code is removed from the build and the daily build is then released.  The team must fix the bad code before any new functionality is added to the code base.

The Development Team should also automate their legacy acceptance tests and other system tests and have these run on the daily build. Legacy tests will most likely not be automatic but the team can add user stories to the product backlog to create automatic tests.

The Scrum Guide places the responsibility for educating and training the Development Team, along with the Product Owner, on the Scrum Master. Getting the Development Team together and ready for their first sprint is the easy part; the Scrum Master must now teach the concepts and intent of Scrum and Agile to the Development Team until they can do Scrum in their sleep. Hopefully, the day will come when the Scrum Master recognises that the Development Team really doesn't need a Scrum Master anymore.

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

Before the First Scrum: Velocity

Before an organisation goes Scrum, they're most likely to be following a waterfall paradigm and using Function Points, Lines of Code (LOC), Analogy, etc., for software estimation in hours per task. They'll probably also use Earned Value or Microsoft Project as a means to measure their progress and ultimately, their profitability. In Scrum, story points are generally used as the estimation mechanisms and Velocity is used to measure progress and, indirectly, profitability.

Velocity In Hours

If the Scrum development team chooses to use hours as their estimation mechanism then velocity is easily arrived at: (number of team members * effective hours/day) * number of days in sprint. Using hours has a certain appeal to teams unfamiliar with Scrum and story points but using hours implies a estimation precision that simply doesn't (and never did) exist. Another issue with using hours is the 'User Stories' can read more like the waterfall-ish requirements that preceded them and be of a technical nature. Although these may capture the basic functionality, they may fail to grasp the end users' point of view, give little or no hint of usability, and tend to read like development tasks; telling the development team how to implement the feature.

Unlike estimating in hours, story points are at best only an approximation of the effort required. The Scrum Master should steer the team toward using story points as soon as practical.

Velocity In Story Points

Prior to the first sprint, have the development team define a reference user story. A reference user story is one were the entire development team can reach an agreement on the effort involved in developing the feature, the complexity of developing it, and the risk inherent in it. This can be one of the user stories the product owner has written for the team or can be some small bit of previously implemented functionality that is familiar to the team. In either case, the reference story is usually something that can be completed by the whole team within a day or two. Once the reference user story is established, give this story 2 story points. All other user stories are estimated compared to this 2-point reference story. A story that is assigned a 4 should be twice as much as a 2-point reference user story. A story assigned 1 is one-half as much as the 2-point reference user story. The actual length of time eventually becomes unimportant. Planning Poker is probably the best estimation technique to use when estimating user stories.

All stories considered for the first sprint are estimated by comparison to the reference story. The team selects and estimates stories they believe can be completed to the satisfaction of the team's Definition of Done in the first sprint (see Definition of Done: How to Ensure Compliance). The total count of story points becomes the team's initial estimated velocity.

Velocity Is For The Scrum Team

Once the team has arrived at an estimated velocity, the Scrum Master can then begin using this as a KPI for the team. However, care should be taken to ensure that velocity is not used to compare between teams (see Velocity as a KPI in Scrum). The Scrum Master can track the team's velocity and over time, measure the team's performance (see  Increasing Velocity Vs Stable Velocity).

Tweet