SM / PO Cheatsheet: Simple guide to the difference between a Scrum Master and a Product Owner

By Edward Scotcher

This is a simple one page aide memoire that can be used to help explain the responsibilities of the role of Product Owner and Scrum Master. It's great to print off and hand out to people when you are explaining what the roles are and what the differences are between them. So next time you need to talk about these roles, you can use this as a basis for a simple discussion or presentation.

Scrum Master's Responsibilities

• Responsible for helping the team deliver work to the Product Owner
• Makes sure the team can meet its commitments by removing any impediments they face, including Managing dependencies, escalating blockers that they cannot remove themselves
• Facilitates process & meetings (eg Reviews, Stand Ups, Planning, Estimation, Scheduling, Prioritization)
• Makes sure the team is fully functional, productive and improving quality
• Shields the team from distractions and interferences (including the Product Owner)
• Enables close co-operation across all roles and functions, removes barriers
• Responsible for reporting progress, including producing standard outward-facing artefacts
• Manages Product Owners expectations of the team
• Responsible for keeping time and quality requirements

Continue reading this article.

Scrum & Gaming Addiction: How Scrum is like online gaming in creating engagement (and even addiction) in your organization

By Pete Behrens

There are few people in our Scrum Community who know personally the power of video games to engage people, and even create addictions to them. There are even some who have applied Scrum to creating those addictive online video games.

This article is not about applying Scrum to gaming applications; rather, it is about the similarities Scrum has to the gaming world in what makes them so addicting. Video gaming is one of the largest growing markets in the world at $50B this year and is on target to be three times the music industry by 2014. This year alone, there was $8B spent on virtual goods in online gaming systems - a true market indeed.

We can learn a tremendous amount from the viral and exponential growth of the video gaming industry. What makes these video games so interesting, engaging and addicting; and what can we learn about them in making our organizations more interesting, engaging, and even addicting?

Continue reading this article.

Effective Retrospectives & Reviews: A CSP’s perspective on continuously improving both the process and the product.

By Marco Mulder

Continuous improvement is a key principle of Scrum. Yet, though most Scrum teams conduct a sprint review and a retrospective at the end of each sprint, too many teams fail to implement the improvements they identify. In my experience, there are two common causes for this:

• Teams don’t have or maintain explicit standards for their product and process;

• Teams don't use the product backlog to schedule improvements.

Set a Dynamic Standard

A definition of done in Scrum defines general acceptance criteria to which all implemented features should adhere. This ensures that everyone has the same understanding of what it means for a feature to be “done.” Team members must all know these general acceptance criteria so that they know when they’re finished. The product owner and stakeholders need a definition of done so that they know what they can expect from the features delivered by the team. That does not mean, however, that the initial definition of done is the one you will want to use throughout the project's lifecycle. In fact, one of the reasons why an explicit definition of done is important is that it not only says what will be included in each feature, it also makes explicit what is not included. Some of the things not included may be planned additions later in the project.

Continue reading this article.

Can Scrum Support Six Sigma?

By Heitor Roriz Filho

INTRODUCTION

This article discusses briefly how Scrum could support Six Sigma projects. Issues of whether Six Sigma is used specifically in software or other product development are not considered. If you ask yourself "Why should Scrum support Six Sigma projects?" I can promptly reply, "Why not?"

Moreover, the question of how Scrum, a lightweight framework for project management and other predictive and detailed methodology have led to process improvement has already been addressed in [2] [3] [4] [7].

SIX SIGMA ASPECTS OVERVIEW

Six Sigma can be considered a detailed and structured methodology to execute projects in a company. To ensure the success of Six Sigma methodology implementation, some critical factors must be verified. A study by McAdam and Lafferty reveals the necessity of employer's empowerment applied with the right tools and methods, in order to achieve the Six Sigma proposed goals in an autonomous and responsible way [14].

Six Sigma as a new paradigm of excellence can result in a huge amount of investment, and it can be questioned if there are other methods that require fewer resources and achieve similar results. Six Sigma still has a long road ahead until it can be accepted as a change philosophy applied to companies in general [14].

In parallel to this movement, another methodology called Lean Manufacturing or Lean Production was developed, and the union of these two process improvement methodologies is called Lean Six Sigma. Originally focused on improvement with a special attention to losses reduction, the concept became one of the most important points of Taiichi Ohno's philosophy, the mentor of the Toyota Production System (TPS). Combining JIT, KANBAN, Quality Circles and CEP, he focused on saving Toyota from a big crisis during the 50´s, which they not only overcame but also won the Japanese Quality Award, the Deming Prize.

Nowadays, many consulting companies look for Six Sigma experts as well as experts in Program and Lean Production, and even though training costs remain above average, many companies are still embracing these programs. On the other hand, some online communities such as TreQna (www.treqna.com) are freely sharing Six Sigma and Lean Production concepts, ensuring many options to people interested on acquiring such knowledge.

The deployment of any program or strategy always depends on people's behavior. In [18] this behavior is divided into two independent and important groups, the top management and the people in charge of the program implementation. The behavior of these two groups is strongly related to their creeds and values, and significantly contributes to the implementation success of a process improvement program such as Six Sigma.

SIX SIGMA ROLES AND METHOD

Six Sigma is based on a people structure of three main roles, Champions, Black Belts, and Green Belts working in a framework such as DMAIC (Define-Measure-Analyze-Improve-Control), a 5-phase method based on PDCA and focused on problem-solving. The Champions have the responsibility to properly define the project scope (during the Define phase) and support the project during the other phases. The Black Belt has the responsibility to communicate frequently with Champions and team members during the project execution, and act as a project leader. Green Belts act as team members and play an active role in the Measure, Analyze, and Improve phases. Finally, all members work together to ensure the sustainability of improvements during the Control phase.

THE SCRUM ROLES

Scrum is focused on its process, three roles, and some artifacts. The three roles in Scrum are the Product Owner, the ScrumMaster, and the Scrum Team.

The artifacts in Scrum are the Product Backlog, the Sprint Backlog, and the Burndown Graph. The Product Backlog contains a prioritized list of the client's needs, i.e., all activities to be performed in order to get the product done. This list is prioritized according to the client necessities; the more business value, the higher on the list the activity will be placed. The Sprint Backlog is a list of activities broken into tasks that are selected in the beginning of a Sprint (a time-boxed iteration usually ranging from two to four weeks). A Burndown Graph displays the remaining work in a Sprint. The literature about Scrum artifacts is vast. More on the artifacts can be found at [10] [11] [12].

The Product Owner (PO) has several responsibilities in a project ranging from defining the product vision to managing the Return on Investment (ROI). The PO represents the needs of the client in a project and is in constant and close contact with the client as well as with the Scrum Team and ScrumMaster. The ScrumMaster is a facilitator in the Scrum process. He is the one responsible for ensuring that Scrum is correctly understood and is correctly followed by the team and PO. The Scrum Team is comprised by those who actually perform the activities necessary to get the product done during the several Sprints.

The Product Owner builds the Product Backlog, a prioritized list of the client's needs. These needs are expressed and/or written in the form of User Stories [14]. Before starting a Sprint, the Scrum Team, the ScrumMaster and the Product Owner perform the planning in a ceremony called the Sprint Planning Meeting. During this meeting the stories with higher priorities are thoroughly discussed and understood by all involved in the process. The Scrum Team then takes these stories and breaks them down into activities, which are the tasks needed to be performed in order to get each story done. These activities comprise the Sprint Backlog.

With the Sprint Backlog the Scrum Team starts to perform in the Sprint. During each day of the Sprint, the Daily Scrum takes place. During this 15-minute standup meeting, each member of the team answers three questions: What did I do yesterday? What I am going to do today? Are there any impediments? It is important to point out that the ScrumMaster acts as a facilitator during the whole process. During the Sprint he will be the one responsible to check whether the Scrum Process is being correctly followed and will protect the team from external interferences, including facilitating the removal of all possible impediments for the tasks.

At the end of the Sprint an increment of the product is delivered. Two ceremonies are performed, the Sprint Review, where the potentially deliverable product increment shall be accepted by the Product Owner, and the Sprint Retrospective, where the team discusses improvements that can be done during the next Sprint. These improvements range from changes in artifacts to better personal interaction.

We can see in this section that Scrum has a very simple yet immutable core process. It is important that this remains unchanged; otherwise we will not be speaking about Scrum, but something else. The next section will talk about how to blend this Scrum kernel into Six Sigma's.

BLENDING SCRUM INTO DMAIC

Scrum is extremely critical regarding the pureness of its architecture while Six Sigma is focused on reaching high quality products performance through variation reduction. The combination of these two concepts can be extremely powerful to bottom-line applications, mainly because Scrum has a strong alignment with lean principles. Furthermore, Six Sigma implementations blended with Lean principles (Lean Six Sigma) can be found in the industry and have become subject to many studies. We believe this diversity ranging from Lean and behavioral aspects and thoughts to predictive and detailed ideas can lead to better performance [5]. As pointed out by [15], Six Sigma should not focus only on the "how to do" the continuous improvement, evaluating the processes performance and business results, but also verify the people engagement and motivation. Therefore, both concepts can combine and complement each other, improving results.

Focusing on high quality products performance and establishing metrics based on statistics, Six Sigma manages a strong, continuous improvement of the manufacturing process. On the other hand, Scrum is a people-centered approach. Its essence surrounds its process and it has a profound effect on people's behavior: it affects the level of commitment in projects tending to facilitate the adoption of new ideas, i.e., it fights the resistance to change.

I start by grouping Six Sigma in six perspectives as shown in Figure 1 below.

The focus on clients' perspective aims to determine the VOC (Voice of Client) variable. Scrum has a very strong focus on the client. The client has its voice through the role of the Product Owner, which acts as a proxy of the client and communicates to the Scrum Team her vision and goals in the scope of the project. The fourth perspective is strongly based on statistical measurements. While Scrum has no predefined statistics in its core, it does aim to achieve improvement through collaboration and communication, i.e., developing strong and fruitful interactions among people. For these two perspectives it does not matter what process tool is used: DFSS, DMAIC, DMADV, etc.

DMAIC is one of the tools found in the perspective number 3 above. The steps defined by DMAIC is where Scrum can produce more tangible results and establish how both concepts intermingle as this is where project management initiatives in Six Sigma are located.

In order to apply Scrum in a Six Sigma project, we propose the following correlation among the roles of both concepts, shown in Figure 2 below.

One of the common mistakes that organizations make when implementing statistical thinking as in Six Sigma implementations is using measurement for motivational purposes [6]. Scrum as a PM framework can collaborate with Six Sigma leveraging the commitment of the team in both Operational and Managerial levels as depicted in Figure 3 below.

In order to blend Scrum and Six Sigma concepts, we consider that an organization comprises two parts, namely the managerial and operational level. We can then visualize the enterprise in terms of project management, where in the managerial level we find all types of executive work, except project management itself. Project management activities can be found in the operational level.

In the managerial level, Scrum would leverage the premise of any Six Sigma implementation, i.e., the support of senior executives. Applied to this level one can setup business-specific Sprint and Product Backlogs and run their activities according to Scrum's Heart and Soul [11]. This approach has been termed Executive Scrum by Magno [8].

The operational level is where DMAIC comes into play. Defining, measuring, analyzing, improving, and controlling are done during project execution. Champions (executive board) determine priority of upcoming tasks according the last DMAIC cycle. This prioritization comprises the Sprint Backlog for one Sprint.

CRITICAL ASPECTS TO CONSIDER

Six Sigma's VOC is a critical aspect of the methodology. This is generally not considered as much as it should be in any Six Sigma implementation. Deming's system of profound knowledge has four points [16]:

1. Appreciate the system.
2. Understand variation.
3. Theory of knowledge: PDCA as constant improvement.
4. Psychology. In our case, understand what engages people in their work.

Generally, Six Sigma is seen as being focused mostly on points 2 and 3. The point is that it does not matter how precise or improved a process can be if it does not meet the client's needs. Points 1 and 4 of Deming's system are those that interface with client's needs. This is where Scrum comes into play, as it has a strong focus on this and aims to work in collaboration with clients during every Sprint.

REFERENCES

[1] H. TAKEUCHI AND I. NONAKA, The New New Product Development Game, Harvard Business Review, 1986.

[2] JAKOBSEN, C. R. AND SUTHERLAND, J. Scrum And CMMI – Going From Good To Great. Are You Ready-Ready To Be Done-Done? In Agile 2009, Chicago, 2009.

[3] SUTHERLAND, J. ET AL. Scrum and CMMI Level 5: The Magic Potion For Code Warriors. In Agile 2007. IEEE Computer Society.

[4] GLAZER, H. ET AL. CMMI Or Agile: Why Not Embrace Both! Software Engineering Institute, Carnegie Mellon University. November 2008, Technical Note Cmu/Sei-2008-Tn-003.

[5] PAGE, S. The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton University Press, 2007.

[6] PAULK, M. C. AND HYDER, E. B. Common Pitfalls in Statistical Thinking. Carnegie Mellon University. In ASQ SOFTWARE QUALITY PROFESSIONAL, VOL. 9, NO. 3, JUNE 2007, PP. 12-19.

[7] PAULK, M. C., Extreme Programming from a CMM Perspective. IEEE Software, Vol. 18, No. 6, November/December 2001, pp. 19-26.

[8] MAGNO, A. Scrum Executivo. AdaptWorks, São Paulo, 2007.

[9] SIVIY, J. M. AND FORRESTER, E. C. Accelerating CMMI Adoption Using Six Sigma. Carnegie Mellon University, Software Engineering Institute, 2004.

[10] SCHWABER, K. The Enterprise and Scrum. Microsoft Press, 2007.

[11] SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2007.

[12] SCHWABER, K. AND BEEDLE, M. Agile Software Development with Scrum. Prentice Hall, 2001.

[13] http://www.scrumalliance.org. Scrum Alliance website.

[14] COHN, M. User Stories Applied.

[15] MCADAM, R. and B. LAFFERTY, A multilevel case study critique of six sigma: statistical control or strategic change? International Journal of Operations & Production Management, 2004. p. 530-549.

[16] http://deming.org/index.cfm?content=66. The W. Edward Deming Institute. Accessed: 2010-01-29.

[17] CORONADO, R.B. and J. ANTONY, Critical success factors for the successful implementation of six sigma projects in organizations. The TQM Magazine, 2002. p. 92-99.

[18] PFEIFER, T., W. REISSIGER, and C. CANALES, Integrating six sigma with quality management systems. The TQM magazine, 2004. pp. 241-249.

Requirement analysis and Design flow in Scrum

By Yi Lv

When do requirement analysis and design activities happen in the Scrum framework? How is our understanding of requirement and design analysis valuable in the Scrum framework? This article describes how these elements flow through Sprints within the Scrum framework.

Requirement analysis is one of the major activities in backlog grooming (the others are estimating and splitting). Once the Product Owner gets an idea by working with customers and adds one vague item into Product Backlog, the item will be groomed for the first time. Considering priority, this item and other smaller items are groomed through several rounds while the Team gets ready for Sprint Planning. The clarity of the items advances in each round of grooming. Acceptance criteria may be drafted in the grooming rounds before Sprint Planning. In the first part of the Sprint Planning Meeting, the requirement analysis continues. If you are able to continuously groom properly, the requirements will be well understood by that time. However, since items are selected in the Sprint Planning Meeting, only then is the Team sure that they are working on them. The Team normally identifies further points (e.g. exact scope, sad path scenario) to be clarified. This may be conducted by working out more details in the acceptance tests. The requirement analysis activity does not stop in the first part of the Sprint Planning Meeting, but continues in the second part and during the actual Sprint. In the second part of the Sprint Planning Meeting, while you are decomposing tasks, the ambiguity in requirement may surface again and be clarified. During the Sprint, test case design, modeling workshop, requirement discussion while designing and coding, and discovery from exploratory testing all contain some element of requirement analysis. Even in the Sprint Review, you will see requirement analysis activity through feedback and suggestion for improvement (new items).

When do we start design? Traditionally, we start design to move from problem domain to solution domain immediately once we get big Product Backlog items. This early move reduces the flexibility in terms of prioritization, which is not recommended in Agile development. We continue to work in the problem domain by keeping the customer orientation as much as possible while splitting the items. The splitting in the problem domain happens in backlog grooming. We also estimate the size of items in backlog grooming. Sometimes, you will have difficulty in estimating the item size, which may be caused by either vague requirements or a lack of experience. If the requirements are vague, requirement analysis in further rounds of grooming helps. If the solution is unknown, architecture or a design spike item can be added in the Product Backlog. This item is normally time-boxed, and its done criteria differ from those of normal backlog items. The output is the sufficient understanding to enable your estimating and planning. In the context of multiple teams working on the same code base, a joint design workshop may be conducted to synchronize the design across teams. In the second part of the Sprint Planning Meeting, the Team commits how much to do in the coming Sprint. In order to make the commitment, the Team normally makes the detailed plan by decomposing items into tasks and estimating those tasks. The commitment may be made based on velocity, but the Team may still think of tasks necessary for them to get the committed items done. How do you determine the tasks? You design. In the second part of Spring Planning, some teams jump into the task decomposition, and get a similar list of tasks such as design, coding, unit testing, review, and functional testing. This indicates a lack of design. How much design do we do in the Sprint Planning Meeting? It needs to be sufficient to support planning. The purpose of Sprint Planning is not design, even though there is a design element in the planning meeting. Besides, the planning meeting is constrained by a time-box, so the Team must find a way to make the best of the time. Design continues in the Sprint. The Team may organize a design workshop, or have an ad-hoc modeling discussion while coding, and coding itself is design. Our design is considered done when the item is done.

In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).

Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review

Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done

This flow allows for requirement analysis and design within the Scrum framework.

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

What Would Gordon Ramsay Do? Or How I Learned to Stop Worrying and Love Difficult Coaching Assignments

By Jan Beaver

A quick Internet search turns up a large number of blog posts comparing and contrasting the approach of Scottish chef Gordon Ramsay’s restaurant management philosophy to Agile software development practices. There are certainly some parallels, although the comparisons break down when one considers Ramsay’s command-and-control philosophy in his own restaurants.

A better analogy is to compare his approach in the restaurants of struggling restaurateurs to coaching Scrum teams and the organizations in which they live.

In case you are not familiar with Gordon Ramsay, he is a highly successful chef, restaurateur, and television personality. Of his three television programs, the one I will focus on here is “Kitchen Nightmares,” a situational reality show in which Ramsay spends a week at a struggling restaurant in an attempt to transform it into an efficient, effective, and profitable enterprise. Aside from the part about spending just a week on-site, this is an adequate description of the daily life of an Agile coach.

As with most successful business people, Ramsay has a formulaic approach, but one in which the areas of nuance are nearly endless and therefore lends itself to just about any situation. His formula echoes many of the principles we Agilists hold dear: do the simplest thing that will satisfy your customer; never, ever compromise quality; work as a team; deliver in small increments, frequently; and finally, give people the environment and support they need and trust them to get the job done.

The typical setup for an episode of “Kitchen Nightmares” goes like this: Gordon arrives at the struggling restaurant around lunchtime, meets the owner or owners, orders some food and delivers his critique to the kitchen staff, observes an evening service in both the kitchen and the dining room, and finally interviews the staff and owners to find out just how close to emotional and financial collapse they really are.

After Gordon has all of the information he needs, he makes a series of recommendations, generally focused on simplifying the menu, reducing prices, changing staff relationships or, surprisingly rarely, changing the staff, updating the décor, and most disturbingly, cleaning the kitchen. While he rarely gets too much pushback on the cleaning angle, most of the staff, from the chefs to the wait staff to the owners, simply balks at changing any of the other items on his list. How much does this sound like certain coaching engagements? They know that they are failing; yet the chefs and owners refuse point-blank to embrace changes that have an excellent track record in delivering success.

At this point, Chef Ramsay uses his powers of persuasion to convince or cajole the owners or chefs or both into adopting his proposed changes. Ramsay is famously profane, which makes for entertaining television, but upon closer examination, his approach is far more subtle than simply dropping a flurry of F-bombs every ten seconds (which he does). First, if he encounters arrogance, he does everything he can to confront and overcome it. This is where the great entertainment lies. As Agile coaches, we confront arrogance regularly. Unfortunately, we cannot look to Chef Ramsay for our techniques. Maintaining the highest levels of professionalism is not optional. That being said, however, we can follow his example by working assiduously to overcome arrogance that blocks necessary change.

Another subtlety in Chef Ramsay’s approach is that he frequently encounters chefs or owners who have simply lost confidence or are so close to the precipice of financial disaster that, paralyzed by fear and uncertainty, they find it impossible even to think of changing anything. With these people he takes a much kinder and gentler tack. In the case of one struggling chef/owner who was about to lose both his prized Michelin rosette and his business, Ramsay offered encouragement, emotional support, and practical guidance based on his long experience as a chef. He uses the same approach with owners for whom it had all somehow gone terribly wrong. Nary an F-bomb drops during these encounters.

So how can we apply Chef Ramsay’s approach to coaching Scrum teams? Easy – follow his program.

First, Clean Up the Kitchen

It is truly shocking how filthy some restaurant kitchens are. A dirty kitchen simply cannot produce quality food. Scrum teams suffer from a similar malady. If the team’s work area is poorly organized or if the team is not at least mostly co-located or lacks high-bandwidth communication, it is very unlikely that they will be able to deliver a quality product. If the team lacks adequate hardware, monitors, has no team room, tries to function without collaborative tooling including information radiators, does not have automated build, test, and continuous integration infrastructure, or does not follow sound engineering practices, it is almost impossible for them to meet customer expectations. So, clean up the kitchen! As a coach, help the team work with facilities and management to get the necessary physical infrastructure in place. Be creative, particularly when budgets are tight. Many of the infrastructural impediments teams face can be overcome without breaking the bank.

Build the Team

Most restaurants that call for Chef Ramsay’s intervention suffer from severe team dysfunctions. Often there are conflicts between members of the kitchen staff, between members of the front-of-house staff, and also between the two groups. The intra-team dysfunctions make it impossible for the kitchen or front-of-house to get organized so that they can deliver quality products to the restaurant’s customers in a timely fashion. The inter-team dysfunction prevents the restaurant from operating as a cohesive organization. Ramsay’s approach is typically to attack the dysfunctions of each team first, so that both the kitchen and front-of-house work cooperatively internally, then he tackles the points of friction between the two teams.

Ramsay always assumes that the people currently working in the kitchen or front-of-house will continue to do so, but as two unified teams working in parallel to delight the restaurant’s customers. He occasionally uses external team-building exercises, but most often works with the two teams in-house to build their sense of team, mutual trust, and inter-team cooperation.

Within each team, Ramsay works to break down arrogant behavior and build individual and team confidence. While restaurant teams are less self organizing than Scrum teams, the idea is much the same, with each team member contributing whenever and wherever possible to complete and deliver each order quickly and with the highest possible quality.

Most episodes end with the staff intact on both teams after Chef Ramsay has done his work. Sometimes, however, the restaurant owner ends up sending one or more individuals packing, either on Ramsay’s recommendation or as a result of team decisions. As with Scrum teams, an individual or two who are unwilling to work in a team environment will derail the entire effort. Ramsay only has a week to rescue a failing business, so he has no time to fool around with people who are disruptive, unmotivated, or otherwise unwilling to invest themselves in the project.

The payoff, for those team members who choose to remain, is a healthy and vibrant work environment in which everyone’s contribution is vital and appreciated.

Work With Your Customers to Determine What They Want – Do the Simplest Thing That Will Work

Once the kitchen is clean and the teams are formed and beginning to understand what it means to work collaboratively, Ramsay turns his attention to the product – the menu. Most restaurant owners think they know instinctively what their customers want and express bewilderment or disbelief at the cold, hard fact that no one is buying what they’re selling. Despite his record of success, Chef Ramsay never assumes that he knows anything about the local market and, like any good Product Owner, hits the pavement to find out what potential customers want and what they’re willing to pay for it, as well as to scope out the competition. The inevitable result of his research is that market doesn’t want the elaborate, stuffy, complex – or just plain awful – and expensive fare the restaurateur has been offering, preferring instead simple, local, fresh foods, simply prepared, served in a timely manner, and at a fair price. A simple menu offering five starters, five main courses, and five deserts seems to be the sweet spot. Maximizing the amount of work not done is clearly a virtue beyond the software industry.

Deliver Early and Often to Delight Your Customers

Now that there is a quality product on offer to the market, delivery becomes the key. The food can be exactly what the market wants, but if it is delivered late and cold the outcome is certain – the business will fail. This is the point at which Chef Ramsay tunes the performance of the teams by helping with everything from kitchen workspace location and layout to front-of-house décor and design. The physical environments in which both teams operate must be tuned to ensure that there are no major impediments to product creation and delivery.

Ramsay frequently coaches the teams to communicate continuously, both internally and with the other team. He always seems amazed at how team members think they can get anything done without continuous communication and collaboration.

Never, Ever Compromise on Quality

One of the usual suspects whenever Chef Ramsay visits a troubled restaurant is the quality of the food. Most failing restaurants have severe quality issues, which of course drive customers away. Poor quality is almost always the result of several factors in combination: a dirty kitchen, poorly equipped or badly organized work areas, antagonistic intra- and inter-team relationships, lack of motivation or commitment, an excessively complex menu, use of inferior quality ingredients (although even top quality ingredients can be used improperly), and poor customer service.

With such a maelstrom of dysfunction swirling around him, how does Ramsay even begin working on quality problems? The answer is simple: start in the engine room (the kitchen) and work your way out, as described in the previous sections.

At Regular Intervals, Reflect on Your Process and Plan Improvements

At the end of the first successful evening service, which usually occurs on the last day of Ramsay’s week on site, he facilitates a retrospective session. He is much more directive than a good ScrumMaster would be in a Sprint retrospective, but the idea is very similar. He reviews with the teams what went well and encourages them to do more of those things. He also reviews difficulties and problems, congratulates the teams on overcoming them, and encourages everyone to work to improve both their own work and the collective effort every minute of every day. It turns out that continuous improvement is a priority in the restaurant business every bit as much as it is in software or any other industry. If we try to rest on our laurels, we’ll find them brown and dead before we even know what happened.

The next time you find yourself facilitating a particularly difficult retrospective, Sprint planning meeting, or any of the myriad other situations that face Agile coaches on a daily basis, take a deep breath and ask yourself: What would Gordon Ramsay do?

Challenging inertia through Scrum

By Rahul Sawhney

Inertia is defined as a state of being lazy, sluggish or indifferent. Challenging inertia is about challenging status quo in an organization. It is about how things should be done differently compared to how they are done now. Organizations sometimes become susceptible to failure as they are unable to challenge the status quo due to various reasons.

This is as relevant to software development as it is to any other aspect of an organization’s functioning. In this article, we will examine the following reasons for organization inertia, the consequences for software development, and see how Scrum can help with the following:

• Size of the organization
• Inefficient structure
• Too much or too little process
• Poor performance management

Size of the organization

How does it cause inertia

Slow decision making

As organizations grow in size, managing scale becomes an issue. Bigger organization means management decisions have a bigger impact. Wrong decisions can put the organizations at risk and therefore it becomes necessary to consult a variety of stakeholders within and outside the organization. This implies that the time taken for arriving at key decisions becomes longer.

The increased timeframe for making decisions is understandable for issues that impact core functioning of the organization. However, it is definitely not suitable when the organization needs to adapt its products in a dynamic and tough market.

Consequence

Many organizations do not understand this problem and fall into the trap of slow decision making, even for product development. When innovative ideas fail to reach the customers on time, competition gets an undue advantage. Slow pace of decision making can result in missed opportunities, lost revenue and increased customer attrition. Thus, regardless of their size, organizations need to deliver the right functionality at the right time to their customers.

How Scrum helps

Role of Product Owner

• Ownership of the product backlog and prioritization encourages faster decision making and responsiveness to customer needs even in large organizations. Controlled, yet responsive management of changing requirements helps managing scope with improved turnaround time. The product owner makes sure that the team does not lose sight of what is most important for the customer.

Customer reviews and frequent releases

• Reviews and product demos at the end of each sprint gives the customer representative more clarity on how the end product should work and look. This helps in reducing wastage of effort and money into development of low priority features, when high priority features need more functionality that has yet to be developed.
• Early feedback from these demos ensures the team makes necessary changes related to the most important functionality of the product in the early stages instead of struggling with issues later when it is too late.
• For large organizations the cumulative impact of late identification of issues can be very costly and difficult to ascertain. However, as multiple units within the organization implement Scrum, the positive effect is amplified and inertia is reduced immensely.

Inefficient structure

How does it cause inertia

Communication

Inefficient organizational structures lead to wasted time, effort and money. The wastage mostly results from poor communication channels between people regardless of their team, unit or department. They are also a reflection of an organization’s lack of sensitivity towards customer needs. Traditionally, team members are forced to work as analysts, designers, user interface developers, middle tier developers, database developers, and testers. Work is divided depending on specialization, and it moves from one person to the other in a sequential manner. Such structures create artificial boundaries between people that are difficult to cross. They create a decision vacuum, wherein the buck passes from one person to the other forever, and the issues are resolved at such a slow pace that they would lose their relevance by then.

Power Politics

Inefficient structures promote power politics. They create an environment where people are made to compete with each other endlessly. This often results in situations where they cross each other and spoil relationships in order to get ahead of each other. In such situations, collective ownership is not given its due importance. Often work assignments are driven by authority and processes rather than teamwork and collaboration.

Reduced innovation

Inefficient structures make innovation difficult. Since everyone is focused on their own activities rather than delivering complete functionality, few in the team can see the bigger picture of how what they are doing impacts the end-user. Therefore, sources of new ideas to create innovative products are few.

Lack of collective ownership

We have seen this with step-wise approaches to software development. Business analysts and business owners are responsible for requirements, Architects are responsible for high level design, Designers are responsible for low level design, Developers for coding, Testers for testing, Integrators for integration, and Project Managers for planning, tracking and coordinating their activities. In such a situation, it is the project manager who is blamed, not the team, when a project is delayed. Usually, one way or the other, team members can easily find excuses for not delivering on time by pointing in another direction. Although this works well for everyone other than the project manager, it is the customer who ends up paying for all the inefficiencies. And no one likes paying more than the real value of the product.

Consequence

The problems with inefficient structure are too many and too difficult to resolve. Due to inefficient structure, customer interests take a back seat as everyone involved views his/her interests as top priority. There is often mistrust of the “other” groups and team members as the blame game can start anytime if anything goes wrong. Due to this people play safe. They only do what they are "supposed" to do, or as per the “defined” compartment to which they belong.

The dysfunction is easier to observe at the team level. Some examples are: “Coding can only start when the design is over,” “No changes can be entertained in the requirements since design is already over.” However, the issue extends beyond the team level. When the team size is large or when multiple teams, units, departments and organizations are involved in creating a product, it becomes even more difficult to acknowledge and resolve. It is also possible that there are vested interests in ensuring that the conflicts remain and politics and emotions prevail over common sense. Ultimately, if these issues are not addressed, the customer pays an extra price or gets a delayed product.

How Scrum helps

While there is no easy answer to solving these structural issues, an advantage of Scrum is that it helps in making the dysfunction visible and allows the organizations to take corrective actions. Other than that the following points are worth mentioning.

Keeping the team cross functional

• This reduces bureaucracy and time lag from making decisions at the team level. A cross functional team does not have artificial walls and naturally communicates better internally and with external stakeholders. Teams change focus towards delivering the functionality as a whole instead of delivering one part of the work (e.g. Design, User Interface, Middle Tier, Test etc.). This not only helps team members learn multiple skills, but also aids in immensely de-risking the projects through collective ownership.

Daily Scrums and Scrum of Scrums

• Focus on resolving impediments quickly improves collaboration and avoids getting into blame games. Scrum meetings keep the entire team engaged in the discussions and provide a clear list of impediments towards progress. These meetings also help team members in supporting each other to meet their joint commitment to the product owner. They enhance teamwork and collective ownership, thereby improving communication. When Scrum meetings are conducted well, structural separations between the team members, which slow down the process, tend to fade away.

Sprint planning workshops

• Prioritization of requirements in the product backlog provides better visibility to the team about what needs to be developed and improves transparency in decision making.
• Since the overall scope can be changed at the beginning of every Sprint, business concerns for new requirements are met. Likewise, the IT team's concern about giving upfront commitment on a plan is also addressed, since with Scrum, it is understood that plan needs to be revisited in every Sprint.
• Sprint planning workshops improve collaboration between the business, development, testing, user experience and other groups. These workshops align the entire team towards customer needs and make them give a joint commitment to plan.
• Since all concerned stakeholders are involved in the exercise of scoping and planning, there is a substantial reduction in power politics and improvement in communication, collective ownership and innovation. This eventually benefits the end customers and the organization.

The role of ScrumMaster

• ScrumMaster plays an important role by serving the team and protecting it from outside interference. By helping the team in following Scrum practices, the ScrumMaster ensures that issues are resolved as fast as possible. The role of ScrumMaster helps in improving communication and collective ownership of the team.

Too much or too little process

How does it cause inertia

Artificial Lags

Lack of appropriate levels of process introduces lags that have an undesirable impact on team performance. For example, too much or heavy process leads to an excessive waiting period due to unnecessary checks at every step in delivering the system.

Chaos

While lag is introduced by heavy processes, chaos is introduced by too little process. When there is chaos, team members do not know where to go and whom to communicate about what. Without processes, it becomes a free for all. It is easy to understand why typical software projects need a process wherein communication is well managed and roles are well defined.

Consequence

Heavy processes promote bureaucracy and reduce productivity because, due to the lags they add, things move slowly. As a result, the team is unable to deliver results with low turnaround time and eventually it results in customer dissatisfaction.

How Scrum helps

Just enough documentation and continuous collaboration

• Documenting the needs of users in a concise, yet informative manner and supplementing it with planning workshops, gives the development team a good perspective on end user needs. This eliminates the need for documents to float around within the team for multiple review/rework cycles and reduces a lot of waste.
• Collaboration during planning workshops ensures that all stakeholders have a better understanding of the requirements. This helps in designing better test cases and better code. Eventually it reduces the amount of rework required during later stages due to poorly understood requirements.

Short feedback cycles

• We may encounter several situations where the functionality developed in a Sprint needs to be revisited. For example, we may find that user needs have not been implemented to satisfy the business goals due to bad design/coding, or the requirement was poorly communicated to the team. We may also find that the customer representative changes his view on how the requirement should "actually" be delivered by the time Sprint ends.
• Scrum makes dysfunction visible and encourages bottom-up feedback. Short feedback cycles of Scrum allow corrective action to be taken almost immediately and satisfy the needs of higher priority functionality in the product backlog.

Team Retrospectives

• Just as short feedback cycles help us in revisiting the contents of product backlog regularly, retrospectives allow team members to periodically inspect their ways of working and adapt their processes locally.

Poor performance management

How does it cause inertia

Ineffective goal setting

Sometimes individual goals are set with a view to encourage competition within the team. In software development, this could be counter productive if the parameters selected do not encourage team work and team performance.

Improper status tracking

Monitoring status is an important activity from the perspective of team performance. If the team does not track progress or only tracks activities that have been completed, it could be in for a surprise when the project nears completion. Moreover, if tracking progress is more of a centralized activity instead of team activity, there is a high likelihood of status not being reported regularly or correctly as team members may stop seeing the true value derived from status tracking.

Infrequent reviews

Tracking performance after large intervals makes it difficult to assess performance accurately. Due to this the feedback can be incorrect and/or ill-received.

Consequence

Ineffective goal setting could lead to unnecessary conflicts in the team. It might not perform to its fullest capability in normal situations and could even fall apart in critical situations.

Late surprises due to improper and infrequent status and performance tracking could cause the team and its members to slip from their goals. They might deliver later than committed, deliver with lesser scope or deliver by cutting quality.

How Scrum helps

Metrics focused on team needs

• Working software is the true measure of progress for an agile team. Measuring and setting goals against working software provides the largest benefit. In addition, metrics that focus on day to day activities help the team in assessing its performance against its way of working. For example, the team could track number of build failures and number of acceptance test failures in the integration environment. It could also track how well it follows Scrum and other agile practices it might be using.
• By measuring metrics that are related to team performance and setting goals with respect to those metrics, the team can continuously improve its way of working and give better output.

Burndown charts

• Burndown charts provide visual progress of team’s activities and make status tracking a de-centralized and fun activity. They not only track what is completed, but they also track what is pending on a daily basis. This improves the team’s chances to deliver on time, thereby enabling them to fulfill customer needs on time.

Frequent reviews

• Frequent delivery of working software with Scrum allows the team to review its performance frequently and make course corrections as needed. Frequent reviews of the team’s performance reduce the room for lethargy and provide an incentive to deliver better regularly.

Conclusion

Scrum focuses on results, quick turn around time, short feedback cycles, and collaboration and relevant metrics. This helps an agile team in influencing issues related to size and structure of the organization, software delivery process and performance management. When the use of Scrum spreads at the organizational level, it helps in challenging organizational inertia and making the organization more agile.

The Sprint Review: Mastering the Art of Feedback

By Bob Schatz

The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.

First, let’s understand what the purpose of the sprint review is.  As my friend and mentor Ken Schwaber writes in his first two books, the sprint review is “a 4-hour informational meeting for the team to present to management, customers, users, and the Product Owner the product increment that is has built during the Sprint.”

Focus on the End User

Some companies are reluctant to involve their end users for fear of “scope creep,” others feel they aren’t allowed to ask the end users to be involved, and certain others don’t even know who the end user is! Whatever your reason for not involving them, find a way to do it.

That’s what we did at Primavera when we adopted Scrum back in 2003. We started off demonstrating mostly to our product managers, but we knew something was missing. So we kept thinking about how to increase the value of feedback we were getting, then the obvious solution emerged—we should involve our actual customers! Customer collaboration, remember? So, we started by inviting some of the customers we had always worked closely with and began to expand it little by little.

We had our own challenges to deal with in involving end users. For one thing, we had about 15 Scrum teams all working on the same release of our software. To help keep end users focused, we started using themes for each sprint. Each team had some piece of work that related to the Sprint theme. Having a theme helped end users tailor their feedback towards the theme for the sprint.

Our sprint reviews could best be described as being like science fairs at school. Each team set up a station where they demonstrated what they worked on. The end users, stakeholders, and a few others from our company formed small teams. Each reviewer team started at a different station. We ran 15-minute iterations moving reviewer teams from station to station.  It was an environment of high-energy, excitement, and fun.

Involve the Product Owner

You’ll notice that the product owner was not part of our reviewer teams. Instead, the Product Owner was actually responsible for presenting the project. This deviation from the original book definition of a sprint review greatly improved the dynamics of our sprint review.

Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work.  This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.

Then, when it’s time for the sprint review, the Product Owner should be the first person to stand up, welcome people, and give an overview of the state of the project. The Product Owner should discuss what the overall goals were for the Sprint, what was achieved/not achieved, the quality level of the product, and the release/product burndown.  He should then let the reviewers know what they should be looking for and how to provide the feedback.  After setting the stage, the  Product Owner turns the “show” over to the Scrum teams for the demonstration of functionality.

Understand Group Dynamics

Changing the sprint review audience from a lone product owner to a team or teams of stakeholders and end users dramatically alters the group dynamics. Let’s look at how these roles change once the product owner is part of the presenting team.

Product Owner: The Product Owner is put in a position where he now is acting as a true owner of the product. He has the responsibility and accountability, as part of the overall team, to present the results of their decision-making to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project. Knowing he must do this at the sprint review enforces the discipline to maintain a product/release burndown and know the quality level of the product. Another byproduct of this approach is that any discrepancies between the Product Owner’s representation of the end users’ needs and the actual needs of the end users will surface immediately.

Scrum Team: The Scrum team is now in a better position to present what they’ve done in the sprint with a sense of pride. They get time with the end user, in the best cases face-to-face time. The best way to develop good software that provides the most value to the end user is to know the end user. The team learns how to take feedback, and with every sprint they get a better appreciation for the people they are developing the system for.  Another ancillary benefit is that presenting to the end user takes away the feeling of being graded or judged by the Product Owner. Instead, the team leaves the review motivated and energized for the next sprint.

Company Executives/Stakeholders: When executives and stakeholders are invited to the review, they not only get a great view of the real status of the project, they also get to see their teams in action. Additionally, they get time with the end users to hear directly about their needs. Perhaps most importantly, they learn how to behave themselves. It’s amazing how different the dynamics are when customers are around. Instead of the criticizing and bickering that usually goes on, everyone is on their best behavior, so the review becomes much more productive and motivating.

End Users/Customers/Partners: The end users are the stars of the sprint review. They get valuable face time with the people that are developing the software. They come to feel like they are part of the development team. They are engaged. Because they have been so involved in the product’s development, once it is released and put into production, they are usually the product’s biggest supporters inside their own companies. Having knowledgeable advocates for the product at the customer site can also help reduce the usual flood of support calls that are typical immediately after release.

ScrumMaster: The ScrumMaster’s sole role in a sprint review is to facilitate. She makes sure the environment is set up for all of this great stuff to happen—that the right people, supplies, and facilities are there. And she makes sure the pizza is ordered. This may seem like a small detail, but don’t forget to feed people. Food is a great collaboration tool. We had some great conversations in the times where we shared some food.

Remember, this is not a ScrumMaster show. During the review, the ScrumMaster should support the teams, make sure the end users are welcomed and made to feel like part of the team, ensure that they get a chance to be heard, and stay behind the scenes.

Be Courageous

If you want to master the art of feedback, the first step is to create an environment that allows it to happen. It can be scary to involve the end users in the process but remember: it’s better to hear the feedback early and have time to make adjustments than to go down a long path only to find out it was the wrong one. Still afraid of scope creep? Let it go. First, the Product Owner will make the decisions on what trade-offs will be made after each sprint review; and second, you may find out more about what the end users don’t need, which will stop overproduction of features that may never be used.

Focus on the end user, create energy and excitement, and make your sprint reviews an event that your customers want to be there for. All you have to do is create a review that has direct value for them. Then just sit back and listen. You may be surprised by what you learn.

Scrum Games: Participatory Activities that Illustrate Scrum Principles and Practices

By Michael de la Maza

Three years ago I learned how to fly a plane. Before I got into the cockpit, I read books and magazines and watched videos on flying. I spoke to pilots about their experiences. I attended aero club meetings. But nothing prepared me for the vertigo and nausea I felt on my first flight or the terror I experienced when night flying.

Like flying, Scrum cannot be learned solely from a book or from a presentation. It must be experienced. Great Scrum trainers and coaches lead their teams through a wide mix of activities that illustrate Scrum practices and principles to give their teams the opportunity to learn by doing.

One of the key Scrum principles is teamwork: the team cannot be a collection of individuals each pursuing their own interests. This concept is, unfortunately, foreign to many work environments. In contrast, a Scrum team coordinates its activities during various meetings, including the daily scrum and the planning meeting, and through the use of many artifacts, such as the burndown chart.

The ESP (extrasensory perception) game is a very simple game that I have found to be very effective in highlighting the importance of teamwork and in sparking discussions about its value.

ESP Game

The ESP game should be played after the team has gone through a Scrum planning exercise and is familiar with sprints. I have found that at this stage there are many doubts about the necessity and benefits of the various Scrum meetings.  I often find that the team wants to skip or modify a meeting.  The ESP game illustrates the key point that if the team does not explicitly invest in teamwork and communication, it will suffer. The game can also be played during the retrospective meeting by teams that have already implemented Scrum to spur discussion about teamwork and communication.

The ESP game is played as follows:

1. The participants are divided into pairs. If the group has an odd number of people then the trainer or coach should play.
2. Each person is given a set of five to fifteen cards. All sets of cards should be the same. These cards can be standard playing cards, planning poker cards, or index cards created for this game.
3. Each person in each pair selects one card and slides it into the middle. Once both cards are in the middle they are turned over. The players can only show one card at a time.
4. If the two cards match then each player gets a point.
5. The game continues until all cards are exhausted.
6. When all cards match, the game is over. If any cards did not match, then the game is repeated.

During the game, the players are not allowed to communicate verbally or non-verbally. They can only communicate through the cards. The players are not allowed to write on the cards or mark them.

Once all pairs of players have finished (i.e. their cards match for the entire deck), then the pairs can be grouped together to form sets of four people and the ESP game can be repeated. The players receive a point only if all four cards match. Smaller groups can continue to be grouped until all of the players are in one large group.

Note that while there may be many logical ways to sort the cards (in numerical order, in alphabetical order, etc.), the greatest challenge is in agreeing on the order without any sort of meta discussion. If, in the first round, one player sorts the cards in high to low order and the other player sorts them in low to high order, neither player will know whether to repeat the original order or to switch orders in the second round. Typically, one player will eventually follow the order selected by the other player. When the pairs are then grouped together the leader/follower behavior must change because each pair has a leader and, unless the order happens to match, one of them must follow.

Discussion

When the activity is completed, invite the participants to engage in a discussion. Here are some questions that often spark conversation:

1. What did you learn?
2. How much simpler would the ESP game be if you could speak with the other player?
3. In your current work environment do you ever feel that you are playing the ESP game? If so, why?
   - What Scrum meetings and artifacts ensure that you will not fall into the trap of coordinating your work effort by playing the ESP game?
   - What might happen if you eliminate these Scrum meetings and artifacts?
4. In your current environment...
   - How do people coordinate their work?
   - Is coordination a first-class object?
   - How often do coordination problems occur?
   - Is teamwork highly valued?
   - Is the team in sync?
   - How are promises and expectations managed?
   - How does the team respond to coordination failures?
5. How can your team improve its teamwork?

Scrum games such as the ESP game serve to illustrate the value of Scrum principles and practices. I encourage you to use them when introducing a traditional team to Scrum. Even high performance Scrum teams enjoy playing these games during the sprint retrospective!

Definition of Done: A Reference

By Mayank Gupta

An Agile project has ceremonies (sprint planning, release planning, sprint retrospective, etc.) and metrics (sprint & release burndown charts) designed to ensure that the project is in a healthy state. Unfortunately, many Agile projects fail even after following all the ceremonies religiously. Why? One of the primary reasons is that they are not able to deliver value to the customer at the end of each sprint. They deliver a product at the end of each sprint, but not a product that is potentially shippable. Here lies the root cause of failure. The software these projects deliver at the end of each sprint is half tested, half documented, half refactored and only half ready for release.

An explicit and concrete definition of done may seem small but it can be the most critical checkpoint of an agile project. Without a consistent meaning of done, velocity cannot be estimated. Conversely, a common definition of done ensures that the increment produced at the end of sprint is of high quality, with minimal defects.  The definition of done is the soul of the entire Scrum process.

Before we explore a definition for done, it is important to define another Scrum term: potentially shippable product.

Continue reading this article

The Impact of Scrum Mechanisms on People and Task Orientation

By Rahul Sawhney

Motivated teams develop a reputation of achieving goals and surpassing customer expectations. Sustaining this level of teamwork requires a fine balance between people orientation and task orientation. Scrum is a great way to achieve that balance. Let us see how.

Two sides, One Objective

In team situations, there is often a conflict between people orientation and task orientation. If too much attention is given to either aspect, the other could be neglected, impacting the team objective. Scrum mechanisms can help resolve this conflict when implemented in the right spirit and with correct understanding; however, if they are implemented with incorrect or incomplete understanding, they can be counter-productive.

In the following sections, we will discuss several scrum mechanisms as well as the implications for correct and incorrect implementation.

Implementing Scrum Mechanisms

Product backlog prioritization

If implemented correctly: Product backlog prioritization gives the business the chance to specify how the team can deliver value to the customer. The team concentrates on the most important activities, as defined by the business, and comes out of the planning session with the best possible scope that it can fit into the iteration. If product backlog planning is implemented correctly, team members know that the work they are doing is important to customers and therefore crucial for the business. This motivates them to deliver faster and with better quality.

If not implemented correctly: A clear distinction is necessary between stories that the team needs to deliver immediately and stories that can follow later. If the product owner marks everything in the backlog as high priority (perhaps as motivation to encourage teams to fit more work into the sprints), the teams may come out of the planning meeting with the wrong features in their iteration. Misallocated stories results in a product with features not immediately needed by the end user, which only hurts the business.

Sprint Planning Meeting

If implemented correctly: Sprint Planning meetings give the team an opportunity to display commitment and risk-taking capability. A team whose members jointly give the estimates and agree on them, is more likely to achieve the goal than a team whose members work on the basis of estimations done by someone else. With Scrum, it is the combined responsibility of all team members to meet the commitment. Combined responsibility translates to team members working together during the sprint and supporting each other to meet the sprint goal set at the beginning of the sprint. It is up to the team members, the ScrumMaster and the Product Owner to ensure that the team takes up a challenging goal in the sprint planning meeting. It is important that all team members participate during the sprint planning meeting so that everyone agrees that achieving the goal together is possible. When the team achieves a challenging goal, not only is the task orientation aspect of the project satisfied, but team members get a great sense of accomplishment as well.

If not implemented correctly: If a team sets itself non-challenging goals in the sprint planning meeting (translating into less task orientation), it may feel good in the initial sprints when the sprint goals are met but soon will get bored, as there is no thrill in achieving their goals. Eventually, management or the business will take note of the team’s under achievements, resulting in a bad situation. On the other hand, if excessively difficult goals are habitually pushed down the throat of teams in every sprint, there also will be negative effects on the team, leading to situations like burn-out, non-accomplishment of iteration goals, demoralization, key people leaving the team, and so on. Incorrectly deploying this practice can be a team’s downfall. Teams need to realize this and work towards finding the right balance in subsequent sprints even if they started on the wrong foot.

Daily Scrum Meeting

If implemented correctly: Daily Scrum meetings make visible to the entire team those issues which, without daily scrums, would be partly or totally invisible. Not only do daily scrums help uncover dependencies, impediments, and the real-time status of tasks, they also indirectly show patterns that can help team members realize how they are performing as a group. Individual traits such as performance (good or bad), need for training, ramp-up, and helpfulness are showcased during these daily Scrum meetings. This often creates peer pressure in lagging team members, making them perform better than before, and leads to better team performance from a task-orientation perspective.

From a people-orientation perspective, daily Scrums are a time to address the genuine needs and constraints of team members and for team members to support each other in times of need. Regular contact also brings positive feedback, such as appreciation for things one team member did to support another that might otherwise go unnoticed. This makes even small contributions to the project visible to everyone. As a result, people feel cared for, which helps create an environment that motivates them. Many small contributions add up to a big positive impact on the project.

If not implemented correctly: Task-oriented managers may consider the daily scrum meeting to be a boon. The daily scrum gives these managers real-time information about how team members (read individuals on their team) are performing; it could also give them an opportunity to force their viewpoints upon team members. If the task-oriented manager continues to use the daily scrum as a platform for gathering progress and pushing his viewpoints, the team will be demoralized. Team members may eventually stop attending daily scrums or begin withholding information, either of which would be extremely harmful to team performance.

Retrospective Meeting

If implemented correctly: Scrum teams use the sprint retrospective meetings as an opportunity to fine-tune and make changes to their performance based on experience gained from each sprint. This meeting ensures that team sustains continuous improvements and gives team members a forum to share concerns. It is important that the meeting be moderated well so that the viewpoints of all team members are brought to the table and discussed. From a task-orientation perspective, by looking at both the strengths and weaknesses of the processes that the team followed, this meeting challenges the team to perform at a higher level and achieve better results in each new sprint. From a people-orientation perspective, this meeting boosts team confidence and participation. This happens through sharing and expressing appreciation for the good incidents and help offered / received during the previous sprint. If this meeting is done well, the team takes ownership of action items and implements them in subsequent sprints. The result is an engaged team, in which continuous improvements are sustained.

If not implemented correctly:  If the concept of inspection and adaptation is not well understood by the team, retrospective meetings could turn into a finger-pointing, blame-game session. If discussions in retrospective meetings are used for political gains by some team members, open participation could be hampered and decisions taken in the meeting could be reluctantly accepted. Excessive focus on improvements or on strengths is harmful. While the first could lead to decreased team confidence, the latter could lead to an unnatural stiffness and acceptance of way of working, thereby indirectly discouraging the team from looking at new/better ways of doing things. If retrospective meetings do not have a problem solving focus, they will be perceived as a waste of time, and teams will quickly become disillusioned with the process. That would be unfortunate.

Sprint Review Meeting

If implemented correctly: Sprint reviews give the team an outlet for demonstrating the valuable additions they have made to business owners and other stakeholders. Sprint reviews also provide the team with valuable feedback about the functionality they have delivered. It is important that the feedback be given and taken in the context of functionalities delivered in the current sprint. Positive feedback keeps teams motivated while constructive criticism helps team create better output in subsequent sprints.

If not implemented correctly: As with any feedback, giving feedback out-of-context can be very unhelpful in team situations. For instance, if feedback is generalized, it could either create an impression of excessive under-achievement or unreal over-achievement by the team, which would lead to the degradation of team performance in subsequent sprints. Highly task-oriented customers and management can sometimes be too critical of the team’s achievements. That can be disastrous.

Conclusion

Scrum emphasizes delivering value early and continuously so that customers get the highest return on their investment. Correctly implemented, Scrum mechanisms enhance and sustain team spirit. To derive the most benefit out of these mechanisms, managers, Scrum Masters, Product Owners, and teams need to understand the intent of and need for these mechanisms very clearly so that they can implement them correctly.

Plan of Action: A Retrospective Technique for Creating Actions Tied to Long-Term Goals

By Bas Vodde

While I regularly change all other retrospective exercises, the action planning technique I’ve been using for the past two years has worked so well that I don’t want to change it. That has not always been the case.

Action planning in my earlier retrospective often had some problems. Some of the action items were just good intentions without enough concrete details to make them actionable.  These items focused on some longer-term goal that couldn’t be achieved during the next sprint. The result of this was that nothing actually happened. “Improve communication” is a good example for such an action. Other action items had the opposite problem. These items were very concrete but lacked a clear goal. For example, one action that came out of many retrospectives was to change the time of the daily scrum. We easily accomplished that action, but didn’t move any closer toward our overall goals as a result. If actions aren’t tied to goals, the team gets stuck in short-term thinking and leaves the longer-term, harder improvements simply because they cannot do them within the next sprint.

Action Format

To solve these problems, I ask the team to generate all actions in a specific format, as shown below.

Long-term goal:  Have test automation on acceptance-test level
Now-Action:  Pete will automate one test using Fit

This format helps the team consider a long-term goal for every action. It also helps them create very concrete actions to move the team a step closer to the long-term goal. The now-action has to be one that can be implemented in the next sprint and must be something the team can accomplish itself. The question to ask is, “What can we do?” This does not mean that the action or the goal has to be within the team’s authority. For example, the team might need new, expensive test equipment. The team might not have budget authority to make such a decision. In this situation, the long-term goal could be, “Have enough test equipment so there is no waiting waste”. The now-action might be, “Make a cost analysis for purchasing test equipment and share this with the person authorized to approve the purchase.”

Every sprint retrospective starts with a review of the previous now-actions. If the now-actions are not completed, we invest time, perhaps the whole retrospective, discussing why not and how we could change that. If the now-actions from retrospectives are not complete, then it’s probably no use to even have retrospectives since no improvements are being made.

Action generation and prioritization

Having an action format is of little value if we do not have a method for generating those actions. The first step in action generation is to have every team member individually generate as many actions as possible. Every action is written in the established format (goal and now-action) and written on an index card. This activity is timeboxed to about ten minutes. After the individual actions are generated, we divide the group into pairs. The individuals in each pair explain each other’s actions to each other. The pair selects the most important actions out of their combined actions, trying to limit the total to a handful of actions, for example five. In this phase they can, of course, generate new actions. This activity is also timeboxed, though it’s often finished before the end of the allotted time. Next, the pairs join with another pair to form groups of four and repeat the process, this time sharing only the most important actions they selected from the previous activity. The foursome further pares down the chosen actions, to for example four. This process continues until there is a whole team discussion. At that point the team selects the actions that have slowly emerged to be the most important.

At the end of the selection process, I write all the actions on one flipchart sheet and hand it over to one of the team members. This sheet is then hung in the team’s workspace as a visual reminder. Those actions not selected can be discarded.

For example, in a retrospective with eight people, the following steps would be taken:

• 10 min – Individual action generation.
• 10 min – Pairs select the top five of their shared actions
• 10 min – Groups of four select the top four of their ten shared actions
• 10 min – The whole group selects the top three of their eight shared actions

The process is based on having team sizes that are a multiple of two; however, with some creativity it works for any size group. It might mean that in the first step there is one group of three or in the second step one group of six and one group of four. (The calculations did give me and my co-facilitator a headache in a group of around forty.)

The advantage of this action generation technique is that it combines individual action generation with group action generation. It then slowly, step-by-step, creates consensus on the actions. Everyone tends to stay involved in the process mostly because they have all been involved in the process from the beginning. Also by slowly increasing the group sizes, the more silent personalities tend not to be excluded.

While we generate as many actions as we can, we ultimately select only a few, typically three, to be done in the next sprint. Selecting too many actions is a common mistake in action planning. The effect is a loss of focus and a huge amount of time spent on tracking the actions.

Linking retrospectives

Sprint retrospectives should be linked so that they build on each other and focus on long-term, continuous improvements. One way to link retrospectives is to bring the actions from the previous retrospective into the current one and discuss whether they are complete or not.

Another way of linking retrospectives is to keep the long-term goals from every retrospective, typically by writing them on a flipchart sheet. In every retrospective, then, we display the long-term goals and use them as input for the action generation.

Can we generate new now-actions for these long-term goals? Do we have any new long-term goals that we need to add to the list? Every now and then we go through the list to see which goals are still valid and which ones we achieved. We remove all invalid or complete actions.

Conclusion

I’ve used the action planning technique presented here in countless retrospectives over the past two years.  Without fail, it has resulted in a small number of agreed-upon actions. Whatever other retrospective exercises you use can serve as input for the action planning. This action planning exercise should happen at the end of a retrospective. I hope that sharing this technique will help other teams improve their own retrospectives.

Empowering Teams: The ScrumMaster's Role

By John Hill

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

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

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

Symptoms

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

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

Causes

"Command and Control" Style Managers (including ScrumMasters)

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

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

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

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

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

General ScrumMaster Failings

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

Cure

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

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

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

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

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

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

Conclusion

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

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

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