Chapter 10

Continuous Improvement

One thing that I hope I have made clear by now is that Professional Scrum Teams know they can always do better. They can build a better product. They can increase quality. They can build faster. They can build with less waste. They can learn new techniques that will help them improve personally and as a team. I use the term continuous improvement to categorize all of these goals.

Knowing where to start is a big part of the improvement process. There are tactical improvements, which help the team successfully achieve the Sprint Goal, meet the forecast, and deliver a Done, working Increment while not generating waste or technical debt. Mastering some of the common challenges that Scrum Teams run into will help in this regard. A team can also make strategic improvements, such as learning to become more cross-functional, improving in self-management, and fostering and living the Scrum Values. Individuals can commit to learn more and strive to become more T-shaped. Teams that improve in these areas will see significant increases in learning, capability, and performance.

Note The FBI Sentinel Project is just such an example of a Scrum Team realizing this kind of increase in capability. While working in the basement of the Hoover building, the team finished over 80 percent of the work with just 10 percent of the budget—after a large government contracting agency failed to deliver. You can read more about the FBI case study in Software in 30 Days (Wiley, 2012), by Ken Schwaber and Jeff Sutherland. The Healthcare.gov fiasco is another such example where the team that came in to fix the app used Scrum. HealthCare.gov is a U.S. federal government health insurance exchange website operated under the provisions of the Affordable Care Act. The October 1, 2013, launch was marred by serious technological problems, making it difficult for the public to sign up for health insurance. This spectacular failure spawned a team of Scrum developers who rescued the website from disorganized contractors and bureaucratic mismanagement.

In this chapter, I will look at how to handle common challenges, as well as how to identify and overcome various dysfunctions. I’ll also explore some healthy behaviors you and your colleagues can adopt to become a high-performance Professional Scrum Team.

Note In this chapter, I am using the customized Professional Scrum process, not the out-of-the-box Scrum process. Please refer to Chapter 3, “Azure Boards,” for information on this custom process and how to create it for yourself.

Common Challenges

Many challenges face software development teams, and Scrum Teams in particular. Software development is a complex effort, and anyone who is not in the middle of it will have difficulty understanding that. Even the smartest team members will run into the dilemma of balancing the values of Scrum against getting something out the door.

For example, when an experienced Developer sees the need to refactor a large class, when should they do this? If they put on their propeller hat, their technical side wants to open up the code and start refactoring right now because it shouldn’t take more than a few minutes, tops. However, when they put on their Scrum robe, they want to spend time wisely and in ways that provide maximum value. One team member with two urges. Which one wins? The answer is, of course, “It depends.”

And in that, you can find the primary goal of this section—to address some of the more common challenges facing Scrum Teams and Developers in order to offer solutions, opinions, and advice so that those teams and team members can learn to self-manage and improve.

Impediments

An impediment is anything keeping the team from being productive. Impediments can be environmental, interpersonal, technical, or even aesthetic in nature. Regardless of what the impediment is, or its size, if it’s blocking the team from being productive, it should be removed. Just as the sweepers in the game of curling (a popular winter sport in Canada) keep the path of the stone free from bumps and debris, so should members of the team keep the path of productive product development free from impediments.

Scrum has two formal opportunities to identify impediments: each day during the Daily Scrum and at the end of the Sprint during the Sprint Retrospective. However, impediments can be identified at any time during the Sprint. More important, they can be removed at any time. The problem is not finding the opportunity to identify impediments, but rather getting team members to be open and honest about their existence—and then find a willingness and authority to remove them.

It’s common to hear Developers say that nothing is blocking them. Hearing this repeatedly does not reflect reality and might actually be a smell of an underlying dysfunction. I’m not saying that Developers are patently dishonest. On the contrary, they are often just being optimistic. They have a lot of work to do and can easily find something else to work on. They may not realize that “blocking” can also mean that they are experiencing slow or nonoptimal progress. Also, nobody wants to bother others with something as depressing as an impediment. What they don’t realize is that by sharing their problems with the rest of the team, their honesty and openness might invite others to help remove the impediment. The impediment may just disappear sooner than expected.

Identifying an impediment is just the first step. The more important step is to execute a plan to remove it. Some team members will be able to remove certain types of impediments more easily than others. The Product Owner, or management, may have to get involved. Regardless of the level of difficulty or amount of ceremony involved in removing an impediment, it should still be identified. In other words, don’t keep an impediment to yourself just because you think it will be difficult to remove. If you see something, say something. Blow your whistle.

Smell It’s a smell if I see that a team is not dealing with their impediments. Ideally, any impediment that survives to the next Sprint should be resolved during that Sprint. It’s the Scrum Master’s job to keep a watchful eye on impediments and appropriately nudge the team to remove them. If the team cannot remove the impediment, then it falls on the Scrum Master to do so. I think of the list of impediments as being the Scrum Master’s backlog.

Estimation

Estimating the size of PBIs is a team skill that will improve over time. Initially, the team may not have experience working with the domain, the technology, the tools, or one another. They may not have a common baseline to use for relative estimation yet, either. Relative estimation is the sizing of PBIs by comparing or grouping PBIs of equivalent size (effort, difficulty, complexity, etc.). All of this will emerge and improve over time.

Regardless of how experienced your team is, when it comes to agile estimation, always remember the basics:

• ■   Keep it refined, but not too refined   A big reason for keeping the important items in the Product Backlog refined is to enable more accurate estimation. The Developers should have just enough information in order to estimate a PBI, but no more. Having additional conversations and specifying additional information beyond what the Developers need to estimate is wasteful. Save it until the Sprint where it’s forecasted.

• ■   Estimate as a team   All Developers on the Scrum Team should be involved in the estimation. Each PBI will require different types of activities and skill sets. The entire cross-functional team should be in the room as each item is discussed and estimated. Estimation by proxy—Developers voting on behalf of other Developers not in the conversation— can lead to the wrong estimates and, more importantly, the wrong solution.

• ■   Be less precise   If you want to be more accurate, be less precise. Initially, consider estimating the size of a PBI using T-shirt sizes. This will help with coarse-grain planning. Later, as it becomes more likely that a PBI will be developed (that is, it floats to the top of the Product Backlog), consider using a more precise unit of measure, such as story points. In Sprint Planning, as well as during the Sprint, the team can be even more precise as it estimates tasks in hours.

• ■   Be relative   No two PBIs will ever be exactly the same in terms of complexity or amount of effort to develop. This is our world. To mitigate this while estimating, the team should think in terms of how the size of one PBI relates to another. This size usually relates to effort, but it can also relate to complexity. It doesn’t matter which, as long as the Developers are consistent. By comparing a new PBI with one that has been developed already, the Developers are able to determine if the new one is more work, less work, or about the same. Over time, working consistently as a team, more baseline PBIs will become available that can be used for comparison.

• ■   Don’t translate   Keep any units of measure abstract. Avoid the temptation by you, or the organization, to translate T-shirt sizes or story points into days, hours, or money. Knowing how many days are in a Sprint allows management to reconcile the work the team delivers or, more importantly, to translate the business value of that work into a monetary value. They already know what the run rate of the Scrum Team is per Sprint. From this information, they can determine the business value per monetary unit, which should be the ultimate metric for any organization. Similarly, the Product Owner can also use the number of days in a Sprint and the Developer’s velocity (or Throughput) to assist with release planning and budgeting. Either way, these computations are informative and healthy, and not the dysfunctional type of translation I’m referring to here. Trying to figure out how many hours a “typical” story point equates to or how many dollars a “typical” story point costs is pointless, as well as wasteful.

Note The process of estimation is more important than the outcome. The real value lies in all the information and learning that are gained and uncertainty that is removed as a result of the conversations that estimation demands. In other words, the shared understanding is more important than the estimate number.

When a team new to Scrum estimates features of a new product, in a new domain, using new technology, with new tools, estimates will be way off. As the team normalizes and members become familiar with one another as well as the product and the environment, this should turn around. Eventually, estimation should occur faster and become more accurate. If this is desirable (and it should be), then keep the team together. They will improve.

Smell It’s a smell when I see management break up a high-performance Scrum Team. It’s actually more than a smell—it’s a downright shame. I know what they’re thinking. They’re thinking that they can distribute these individuals to other teams within the organization as “seedlings.” The seedlings will then grow new high-performance Scrum Teams. Although this may be true, it destroys self-management and generates waste due to the length of time that it requires to become a high-performance team. When a team has progressed through Tuckman’s stages of team development (forming, storming, norming, and performing), any change to the team—especially dismantling it altogether—sends everyone back to forming. I contend that the organization will derive more value by leaving that team intact. Bring other team members into the established team as a visitor (akin to a foreign exchange student) or let the Scrum Master nurture new seeds in other teams. This way, you won’t dismantle a proven generator of business value.

Tracking Actual Hours

Tracking actual hours spent on PBIs or tasks is not important in Scrum. Although it’s not too difficult to track this information in Azure DevOps, I recommend teams resist the urge or request to track or compute actual hours. It can only be used for evil. Once actual hours are tallied by task, or by task activity type, somebody, somewhere will use it as a measuring stick, or a beating stick, to attempt to motivate or “improve” the team’s abilities. As I’ve previously explained, improving because someone else wants you to improve doesn’t work. The desire must come from within, not from a spreadsheet.

Note Tracking hours on a timesheet in order to get paid is a different matter. So is the tracking of hours in order to bill a department, a budget, or a client. If management expects this data, provide it. But do so knowing that the totals you are providing have nothing to do with the team’s efficacy. If tracking hours detracts from the Developers’ ability to develop product efficiently, have the Scrum Master do it in order to protect their focus.

Tracking original task estimates is also not important. The only estimate that Developers might want to track is the amount of remaining work left to be done. In Azure Boards, this relates to the total number of hours for all Task work items in the To Do and In Progress states on the Taskboard. These estimates can change daily and, therefore, should be updated at least daily. Hopefully, the work remaining estimates go down. Some days, however, they may go up. Some days, new tasks are identified that the Developers didn’t foresee. This is the nature of a complex effort like software development.

Tip When pressed by management for why original estimates were off, give the honest answer: “What we do is hard.” This simplistic answer is 100 percent accurate and can also be used if asked why the build broke, why a bug escaped into production, why the team missed their forecast, why the team did not achieve the Sprint Goal . . . you get the idea.

For example, let’s assume the Developers estimated that the development of a new mobile-friendly dashboard would be eight story points and the sum of all the hours of the initial tasks would be 120 hours. Let’s also assume that development ended up taking 160 hours to complete the PBI. Should the Developers be concerned about the gap in their estimates? Sure. They should discuss it during the Sprint Retrospective and determine how they might make better estimates going forward. I propose that teams will organically get better at estimating. Should management be concerned about the deviation from the original estimates? Sure, but they should know that their best people are on the job and those people should be given the freedom to self-manage and make improvements themselves. Additional “management” won’t make estimates more accurate.

Note Some teams prefer to break PBIs down small enough where they can be completed in a couple of days or less. This removes the need to perform estimation because each PBI would already be quite small. Effort is still required to split a PBI into small pieces, and this effort may be greater than performing agile estimation. Try some experiments and decide for yourself.

Assessing Progress

Assessing progress means knowing how much work has been done and, more importantly, how much is left to do before achieving a specific goal. This is not necessarily the Sprint Goal, but any goal. The goal could be completing a PBI, completing all forecasted PBIs for a Sprint, completing all of the expected functionality in a release, or even achieving the Product Goal. Progress toward each of these types of goals can be measured in a number of ways.

The Scrum Guide does not provide guidance on how to assess progress other than suggesting that it should be done by the team regularly. Table 10-1 lists the various goals that a Scrum Team will be pursuing, when to assess progress (at a minimum) toward each goal, and some practices that can be used to assess progress.

TABLE 10-1 When and how to assess progress toward various goals.

Goal	When to assess? (at a minimum)	How to assess?
PBI	Daily Scrum	Count related tasks, sum related task hours, count related failing tests, or use Cycle Time and Work Item Age metrics.
Sprint forecast	Daily Scrum	Count PBIs, sum PBI sizes, count tasks, sum task hours, count failing tests, or use Throughput metric of undone PBIs in the Sprint Backlog.
Sprint Goal	Daily Scrum	Similar to assessing progress toward the Sprint forecast, although the Sprint Goal may be independently achievable.
Release	Sprint Review	Count PBIs, sum PBI sizes, or use Throughput metric of undone PBIs planned for the release.
Product Goal	Sprint Review	Similar to assessing progress toward a release, although the Product Goal may be independently achievable.

Assessing Progress Toward a Product Goal

The most popular way to assess the progress toward a Product Goal or a release is to maintain a release burndown chart like the one you see in Figure 10-1. This kind of chart shows how much work remained at the start of each Sprint for a given release goal. Each Sprint appears along the horizontal axis. The vertical axis measures the effort (size of the PBIs) that remained when each Sprint started. The unit of measure is whatever your team has decided to use. Story points are the most common. The data comes from the refined Product Backlog. The more refined the Product Backlog, the more accurate the burndown.

FIGURE 10-1 A release burndown shows progress toward a Product Goal or release.

Note For a long-running development effort, one with multiple releases, the remaining work could actually increase over time as the Product Backlog evolves. In cases like this, the release burndown alone won’t tell you how quickly the team is completing items in the Product Backlog, especially if the burndown refers to more than one release.

Story maps are another way to visualize progress toward a Product Goal or release. PBIs can be put into rows or tagged to show that they are part of the plan. Whether the Scrum Team uses a physical story map or an electronic tool, such as SpecMap, the Product Owner can ensure the plan is visible for all to see. Refer to Chapter 5, “The Product Backlog,” for more details on SpecMap.

Tip Don’t discount a conversation with stakeholders as a way to assess progress. As the stakeholders have been inspecting the product Sprint after Sprint, they might be a good gauge as to whether the release is ready or the Product Goal has been met. A stakeholder’s feedback can be a powerful assessment.

Assessing Progress Toward a Sprint Goal

The most popular way to assess the progress of a Sprint—toward completing the forecast and/or achieving the Sprint Goal—is to maintain a Sprint burndown chart like the ones shown in Figure 10-2 and Figure 10-3. These kinds of charts show how much work remained at the end of specified intervals during a Sprint. These intervals are typically days, and they appear along the horizontal axis. The vertical axis measures the amount of remaining, identified work (either PBI or Task work items) to complete. The data comes from the Developers’ regularly updated Sprint Backlog.

FIGURE 10-2 A Sprint burndown can be based on the forecasted PBIs.

FIGURE 10-3 A Sprint burndown can be based on the remaining hours of tasks.

Sprint burndown charts can show the team how much work remains in the Sprint. These charts will often include a trend line. This line represents the ideal rate at which the Developers are able to complete all of the remaining effort, at a constant rate, by the end of the Sprint. It is usually visualized as a plotted line displayed on the chart. By using the trend line, the team can gauge how it’s doing and know if it is on track to finish all forecasted work by the end of the Sprint, given the constant rate.

Burndown charts are generated from actual data. Because of this they reflect the reality of the Developers’ activity. For example, if the Developers all go away for a three-day training class, the burndown will reflect a flat horizontal line (no movement) for those days. This can also result when new work is added and completed on the same day or if new work is added at the same rate it is completed on the same day.

The Burndown analytic widget can burn down by count of PBI work items, count of Task work items, sum of PBI effort (story points), sum of task remaining hours, or sum of other fields. You can create a burndown for any of the backlog levels: Epics, Features, or Stories (PBIs). In fact, you can burn down by summing any field or by counting any type of work item. The new widget displays average burndown, % complete, and scope increase. You can also choose to burn down on a specific team, which lets a Nexus track Sprint burndowns for multiple teams on the same dashboard. You can learn more about the Burndown analytic and widget by visiting https://aka.ms/configure-burndown-burnup-widgets.

Note There is also a Burnup analytic widget, which focuses on completed work. Although progress can be assessed from a burnup, its primary purpose is showing the Product Owner and stakeholders that the Scrum Team is consistently delivering value, Sprint after Sprint.

Burndown charts can also illuminate other facts about how the Developers work:

• ■   Actual and trend are diverging or are far apart   The Developers will probably miss their forecast. This will happen from time to time, but more often with new teams. As a team norms and performs, their collaboration and estimation practices will improve and velocity will stabilize, resulting in forecasts that become more accurate. On the other hand, sometimes the actual burndown is below the ideal one, meaning the Developers will probably complete their forecasted work earlier than expected and will be able to collaborate with the Product Owner about adding more work to the Sprint.

• ■   The total number of hours is increasing   This occurs when additional work (tasks) are added to the Sprint Backlog during the Sprint. New tasks are to be expected, but a large number of tasks, or new tasks over several days, may indicate poor Sprint planning, a badly refined Product Backlog, or scope creep. This may also be the Developers violating the “You Ain’t Gonna Need It” (YAGNI, also known as gold-plating) principle, which discourages the adding of functionality until it becomes necessary and not just because the users might need it in the future. Regardless of the origin, unplanned work like this becomes quite evident on a Sprint burndown chart.

  

  Note It can be normal for an experienced team to add additional tasks during the first day or two of the Sprint. This indicates that the Developers did “just enough” planning during Sprint Planning. Additionally, teams that are practicing single-piece flow (swarming or mobbing on a single PBI until it is done before moving to the next one) can witness many small spikes in work while they “task as they go.”

• ■   Actual performance is significantly above the trend line   The Developers have really missed the estimates or the amount of work forecasted. Attention should be given to both during the next Sprint Retrospective.

• ■   Tasks move to “Done” prematurely   Reactivating a task by moving it from Done back to In Progress will be reflected on the burndown as a bump. Knowing when a Developer (or pair) is truly done with a piece of work is a practice that will improve over time.

• ■   Tasks are not created for large pieces of work   The Developers should decide when to create a Task work item and when to just do the work. This is dependent on the Sprint length and other team behaviors. The rule of thumb I use is two hours for a two-week Sprint. For example, if a Developer realizes that a Secure Sockets Layer (SSL) certificate is expired while deploying the application to a staging environment, they may want to create a task for the work they are about to do, or they may just want to do the work. Either way, there should be a team working agreement on what triggers the creation of a Task work item.

• ■   Tasks stay “In Progress” for more than 1 or 2 days   Sprint burndowns don’t usually show this level of granularity, but flat spots (or rises) are always a concern. Where this staleness becomes obvious is during the Daily Scrum. Other Developers should be concerned, or at least inquisitive, when one of their team says they are (still) working on the same task for several days. There may be a lack of focus or openness at play here. Keep the burndown, and the team, transparent by updating all of the Remaining Work fields of your Task work items at least once per day.

• ■   Burndown actually burns up   Increasing hours may be due to scope creep, which occurs when a substantial amount of work is added to a Sprint after it is planned. This is to be expected to some degree. Professional Scrum Developers will strive to refine PBIs and effectively estimate work at the beginning of the Sprint.

When an organization first adopts Scrum, the customers and management may still be expecting to see the old management reports and analytics pertaining to development. What they get in Scrum is going to be quite different. There will be a transition period for them to stop using the old reports and begin understanding the new ones. During this period, the customers and management should also learn what it means for the team to be self-managing. This will help explain why the old reports are not necessary anymore. A Professional Scrum Master can clarify to stakeholders that any report or artifact showing progress is primarily for the Developers and that they are being allowed access in order to provide transparency.

Another way to assess progress is to simply ask the Developers. At the Daily Scrum, each Developer can indicate how confident they are in being able to meet the Sprint Goal and complete the forecasted work. If the confidence stays the same or goes up, that’s good. If it starts to drop, that’s an indication that something might be wrong, and one that can be trusted because it comes directly from the front line. This technique for assessing progress can be just as effective as using a burndown.

Renegotiating Scope

In the business world, things can change suddenly. Products being developed to support the business or to sell or support a product or service can quickly become obsolete. Or, thinking about it more optimistically, the product can be modified to take advantage of new opportunities. Regardless of the reason for the change, a Product Owner may determine that one or more forecasted PBIs no longer has value or that other PBIs may have more value once the Sprint has begun. This realization can also be initiated by the Developers if they determine that a PBI is not able to be developed to any degree that would be fit for purpose. The Scrum Team should come together whenever forecasted scope is renegotiated.

Note Renegotiating scope can also mean that the Developers have completed all forecasted work and want to add more PBIs to the Sprint Backlog. In this section, however, I’m talking about the more challenging scenarios where the forecasted work was not completed, has become irrelevant, or new/different PBIs need to be added to the Sprint Backlog after Sprint Planning.

The best-case scenario when renegotiating scope is that the Developers have not yet started work on the forecasted PBI(s). Hopefully, only an hour or less of the team’s time spent planning the work will be wasted. This could include conversations, creating tasks, creating acceptance tests, and so forth. The more complex (and wasteful) scenario is where the scope needs to be renegotiated after the Developers have started developing the PBI.

Obviously, the further into development, the more work will be potentially wasted. The Product Owner should take this into consideration before pressing the “red button” to stop development. It may be more efficient (less wasteful) to allow the existing work to finish, creating a new PBI instead. It is the job of the Scrum Master to help the Product Owner understand the trade-offs associated whenever renegotiating scope. The costs are probably irrelevant if the work the Developers are doing is truly without value.

Smell It’s a smell if I see a Product Owner regularly renegotiating scope. More often than not, it’s a dysfunctional Product Owner at work, trying to continuously introduce new, high-priority work. This dysfunction can sometimes be restated as a lack of proper Product Backlog refinement. It could also be that the Product Owner is new to the role and still getting the hang of effectively ordering the Product Backlog. It could also be that the Product Owner is trying to appease too many stakeholders at once. In any case, the Scrum Master should get involved and make sure that changing scope is truly the exception to the process, and not the rule. Nothing frustrates (and burns out) good Developers like an organization that keeps giving priority 1 work, on top of other priority 1 work. If everything is priority 1, then there are no priorities!

Canceling a Sprint

If it is determined that the Sprint Goal becomes obsolete, the Product Owner can cancel the Sprint. In other words, the Sprint could be canceled if the Product Owner determines that there is no chance to realize any value in any of the forecasted work being developed. For example, if a company suddenly decides to abandon support for a particular platform, the Sprint could be canceled if it only contained PBIs intended for that platform.

Note Only the Product Owner has the authority to cancel a Sprint. The Developers or stakeholders may influence their decision.

Here are some actual examples when a Sprint might be canceled:

• ■   Business conditions change in a way that the PBIs in the Sprint Backlog no longer have value.

• ■   The technology on which you’ve been building the product proves invalid, and switching to a new technology requires a large amount of new planning.

• ■   The organization undergoes a restructuring where Developers get moved off the team.

• ■   Budgetary issues force a radical change in direction.

• ■   Virus or ransomware attack redirects everyone to work on security.

• ■   The organization buys a startup that just released a product with overlapping functionality with what the Scrum Team was working on that Sprint.

• ■   Critical production support issues arise and take the Developers away to the point where they aren’t able to deliver any value in the Increment for the Sprint.

• ■   The organization files for liquidation bankruptcy.

• ■   Patent litigation kills the product.

• ■   New government regulatory requirements negate the Sprint Goal.

When a Sprint is canceled, any Done PBIs should be reviewed to determine if they are releasable. All undone PBIs are moved back to the Product Backlog. If they are still pertinent, they should be reestimated.

When a Sprint is canceled, it means that at least some amount of the work will have to be discarded. Although Scrum minimizes waste through short iterations and just-in-time planning, canceling a Sprint should be the last thing considered. Sprint cancellations consume resources, since everyone has to regroup in another Sprint Planning to start another Sprint. They are often traumatic to the Scrum Team and, as such, are not a good thing.

Tip I know several Professional Scrum Trainers and other practitioners who have gone their whole career without experiencing a canceled Sprint. If your Product Owner is canceling Sprints frequently (even more than once), consider shortening the Sprint instead. I’ve worked with teams in volatile markets who normalized on three-day Sprints for just such a reason. This is an extremely short Sprint, with a relatively high cost in the overhead of the required events, and should be attempted only by high-performance Professional Scrum Teams.

Undone Work

A common problem that Scrum Teams face is that of undone work. The Sprint is over and some things did not get done. Maybe an entire PBI (or two) didn’t even get touched. More likely, however, is that a PBI is in progress with one or more undone tasks, code half-written, tests half-passing, the Definition of Done not fully met, and so on. I refer to that type of undone work as unfinished work. Regardless of how much work was accomplished for a PBI, it cannot be released unless it is done—according to the Definition of Done. Not only would the feature not work correctly, but the Developers will have introduced technical debt into the product.

Regardless of the type of undone work, or its level of “undoneness,” the guidance is the same:

1. The PBI should not be released.

2. The PBI should not be inspected at Sprint Review. Doing so might set expectations that it is done or close to being done or that it will look/feel like this when it is done.

3. The PBI should be moved back to the Product Backlog.

4. The Developers should reestimate the PBI.

5. The Product Owner will consider developing the PBI in a future Sprint.

There are other nuances to consider when dealing with undone work:

• ■   Don’t give partial credit   Points for partially completed PBIs should not be summed into velocity, even partially. The Developers are either done with a PBI (according to the Definition of Done) or they aren’t. The exception to this is when a PBI can be split and a portion completed according to the Definition of Done during the Sprint (see the next bullet).

• ■   Split and release smaller PBIs   If a PBI can’t be delivered in whole, as forecasted, and the Developers determine that it can be split, they should talk with the Product Owner. That discussion might yield a plan to release smaller, logical parts of the PBI—each delivering a slice of value. Splitting on acceptance criteria boundaries is often a good choice.

• ■   Reestimate the PBIs   Undone PBIs should be refined and reestimated. This increases transparency because the new estimates reflect the Developers’ latest thinking. Besides, the new estimates will be more accurate, since the team has firsthand experience. Estimates may be lower than original, because some work was performed. Estimates may also be higher—new complexities may have been uncovered.

• ■   The Product Owner owns the order   It is always the Product Owner’s prerogative to order the Product Backlog at any time, for any reason. This means that an undone PBI from the current Sprint may not necessarily return to the Product Backlog at the top, or even anywhere near the top. In other words, don’t assume that undone PBIs will just get forecasted (rolled) into the next Sprint. This takes agility away from the Product Owner.

• ■   Exclude unfinished work from the Increment   In the event that a Sprint ends with unfinished work, manual effort may be required to exclude the unfinished code and behavior from the Increment. Single-piece flow (limiting work in progress by swarming or mobbing on a PBI) can help alleviate this headache. If this is a regular issue, the Developers can establish a working agreement that they will not advance to the next PBI in the Sprint Backlog until the prior one is Done. For some environments, this is not practical, so other, more engineering-centric solutions are required. The two most common approaches are (1) create a branch per PBI, and (2) use feature flags. I’ve already discussed the risks in using branches in Chapter 8, “Effective Collaboration.” I will cover feature flags in the next section.

• ■   The Product Owner cannot override the Definition of Done   Under no circumstances can the Product Owner, a stakeholder, or the organization override the Definition of Done and say that a PBI is done when it isn’t. Releasing unfinished work decreases transparency, increases risk, and can add technical debt to the Increment.

A releasable product is one that has been designed, developed, tested, and otherwise made Done according to the Definition of Done. This may or may not include the actual release of the product. This means that the Developers may have to create build packages, installers, release notes, help files, and other artifacts to assist in the actual release—as well as releasing—before declaring a PBI, as well as the Increment, Done. Whether or not the Product Owner chooses to release is irrelevant. The Developers must complete all work as if the Product Owner was going to release it. This is another advantage of feature flags. They allow for a PBI to be released, but not necessarily enabled. The Product Owner can then decide, at the appropriate time, to enable the capability.

Smell It’s a smell when a Scrum Team, including the Product Owner, just assumes that undone PBIs will be carried forward to the next Sprint. That may very well be the case, but assumptions like this diminish agility and can lead to unhealthy behaviors, such as compromising on quality. It’s always the Product Owner’s decision what work will be considered for the next Sprint. The Product Owner should listen to the Developers, but that is only one source of input to consider. In other words, it’s a dysfunction to assume that the Developers will just continue working on unfinished PBIs in the next Sprint.

Velocity is just one input to Sprint Planning. Velocity simply indicates how many PBIs (or the sum of story points) a team usually completes per Sprint on average. It is not a commitment or a target and should only be used as one of several inputs for Sprint Planning. For example, just because the Developers were able to deliver 30 points last Sprint doesn’t mean they will again this Sprint. The velocity for future Sprints is always unknown, and Developers can only guess what it will be. These guesses will become more accurate over time because velocity should stabilize as the team improves. It takes courage to stop guessing and trust that the Developers will be able to self-manage and forecast a comfortable amount of work and then deliver the best Increment possible given all the constraints.

Smell It’s a smell when I hear the terms velocity and credit together in the same conversation, or when management tries to compare the velocities of two Scrum Teams. This smells like the Developers are being gamed in some way or are being artificially rewarded somehow. Remember that velocity is just a historical representation of multiple factors from previous Sprints. It is a lagging indicator of the Developers’ output. Using velocity in any other way diminishes its value. Don’t put too much scrutiny, positive or negative, into those numbers. Developers should focus on achieving the Sprint Goal and delivering business value in the form of working product, and not on increasing or stabilizing its velocity. That will happen organically. Velocity should never be the goal.

Feature Flags

A feature flag is a technique where functionality can be selectively excluded, disabled, or enabled from released software. In other words, Developers can modify system behavior without changing code. Feature flags are primarily used as a way to perform a canary release—only enabling a new feature for a small percentage of users. This allows the Scrum Team to “test in production”—albeit with a small group of users, thus limiting the impact of any errors or side effects.

Feature flags, also known as feature toggles, feature bits, feature flippers, and feature switches, are not a new concept. Developers have leveraged this kind of practice by wrapping a section of code with an if/else statement controlled by logic driven from an external data source. This allows teams to control product feature visibility and utility. There are many commercial SaaS feature flag solutions out there, including Azure App Configuration, LaunchDarkly, Optimizely, and Rollout.io (CloudBees). GitHub has many open source solutions. Honestly, it’s not too hard to write your own feature flag implementation, but why would you want to? For more information on open source solutions, visit https://featureflags.io.

As I just described them, feature flags sound more interesting to Product Owners—providing a mechanism to perform canary releases, incremental rollouts, blue/green deployments, testing in production, A/B testing, hypothesis-driven development, and even a kill switch. Another, lesser-known use case of feature flags is as a hedge against undone work and in lieu of using branches.

Essentially, Developers can use feature flags to work on and even release the Increment containing an unfinished PBI. As the Developers start work on a PBI, they can be diligent about putting all related code inside respective if blocks, driven by a feature flag. In the (unlikely) case of an unfinished PBI, its visibility in the UI and functionality can remain toggled off, allowing the Increment to still be safely released and used. Yes, there will be technical debt, but hopefully it will be short-lived. Improved design will be a positive side effect of working this way—mostly to avoid the multitude of if statements.

Ideally, the Developers will finish the partially completed PBI in an upcoming Sprint. Once completed, Developers can toggle the flag on or remove the feature flag infrastructure altogether. This minimizes waste and also ensures the toggled feature doesn’t become long-term technical debt in the product.

Be careful releasing a product with feature flags, since they can (by design) cause different behavior in different deployments, which can make the process of triaging a bug more difficult. Remember that the team will naturally get better about completing its forecasted work and may not need such solutions in the future.

Note Don’t confuse using feature flags in this way with the practice of feature flag–driven development (FFDD), a practice of releasing and iterating features quickly, testing those features, and making lightweight improvements. FFDD is akin to test-driven development (TDD) and Lean UX practices, where features are released to receive market feedback and development iterates on that feedback, making improvements and redeploying. It’s a way to test how your features perform in the real world and not just in an artificial test environment. You can learn more by reading this LaunchDarkly blog post: https://blog.launchdarkly.com/feature-flag-driven-development.

Regardless of how a team uses feature flags, keep in mind that they are technical debt. They may be cheap and easy to add, but the longer that they are left in the code, the more debt is accrued. It can be hard to keep track of which flags were used for which purpose and which flags are even relevant anymore. They add complexity when debugging, refactoring, and testing—not to mention increasing the difficulty to reproduce a bug. Professional Scrum Teams should limit their use of feature flags, review them often, and be merciless about removing them when they are no longer necessary.

Handling Undone Work in Azure Boards

Azure Boards does not offer any tooling for directly handling undone work. All moving or copying operations will have to be performed manually, and doing so can be time-consuming. Because of this, Sprint Backlogs sometimes end up in a less-than-desired state due to the amount of work required to organize them properly. Teams have moved on to the next Sprint’s work, and housekeeping is not a priority. If the Developers are incapable of cleaning up their Sprint Backlog, then it is the responsibility of the Scrum Master to teach or coach them.

When a PBI is not done at the end of a Sprint, the opportunity to work on it as part of the existing body of work is often lost forever. The reason for this is that when the same PBI is planned in a future Sprint, the context for that work may be different. This is why I always recommend that the PBI be reestimated.

When considering how to handle undone work in the context of Azure Boards, there are basically four approaches:

• ■   Move to the Product Backlog   This is the most common approach and fits with my guidance from earlier in this chapter. The PBI work item is simply moved back to the Product Backlog by changing its Iteration Path and State fields accordingly. You can also drag and drop to the Backlog in the Planning pane. Linked work items remain linked. No record, other than notes in the History, indicates that the PBI was ever in the original Sprint. Linked Task or Test Case work items will still be set to the original Sprint.

• ■   Copy to the Product Backlog   The PBI work item is shallow-copied and the copy’s Iteration Path and State fields are set for it to appear in the Product Backlog. The original PBI work item and all linked work items remain in the original Sprint in the Forecasted State. The new PBI has no linked work items, so a brand-new plan (Task and/or Test Case work items) must be created during a future Sprint Planning. The old PBI, and any linked work items, are abandoned and left to the historical record of that Sprint.

• ■   Move to the (next) Sprint Backlog   If the Product Owner wishes, then the Iteration Path of the PBI work item and all linked work items can be changed to the next Sprint. Everything appears just the way it was in the original Sprint. No record, other than notes in the History, shows that the PBI was ever in the original Sprint.

• ■   Use the Split extension   By installing and using this extension, the team can continue working on unfinished PBIs in the next Sprint by “splitting” the PBI into a new work item in the next Sprint. The team can choose to move any of the incomplete tasks forward to the next Sprint as well, as you see in Figure 10-4. For more information visit https://marketplace.visualstudio.com/items?itemName=blueprint.vsts-extension-split-work.

FIGURE 10-4 The Split extension makes it easy to move undone work to the next Sprint.

There will be times that a Scrum Team may want to use each of these approaches. One cannot be prescribed as the “recommended way” without knowing more about how the team works and other factors. That said, I’ll repeat myself and say that there is a smell of dysfunction when a Scrum Team constantly rolls undone work over to the next Sprint—whether manually or by using an extension.

You should consider a number of other activities when copying or moving undone work items in Azure Boards. I’ve listed some of these in Table 10-2.

TABLE 10-2 Considerations when copying or moving undone work items.

Set the PBI’s Iteration to the root after moving or copying to the Product Backlog.

Set the PBI’s State to Ready after moving or copying to the Product Backlog.

Reestimate and reorder PBIs after moving or copying them to the Product Backlog.

Clear all Remaining Work values for undone Task work items (they will be reestimated).

Clear all Assigned To fields for undone Task work items (they should not be owned by anyone).

Set all states and fields appropriately for other linked work items (such as Test Cases).

Copy all (or just the undone) tasks to the next Sprint Backlog if the plan still makes sense.

Copy Test Case and other work items to the (next) Sprint if applicable.

Add appropriate notes to the History tab of the various work items as needed.

Spikes

There will be times that the Developers may be required to develop something that they haven’t done before. They may not be able to do so, let alone even estimate the work with any confidence. This could include developing a new capability using a new product, component, framework, system, language, or tool. The Developers will need to learn and practice in order to develop the feature successfully. They also need this experience sooner, in order to be able to estimate the size of the PBI and feel comfortable forecasting the item in a future Sprint.

Organizations can’t expect their Developers to gain this knowledge on their own, although some Developers will. I know many developers who consider their profession to be their hobby. For these geeks, learning new things is just fun. For the rest of the world, this learning will have to come during company time, on the company dime. But how does this fit with Scrum? I have a couple of ideas. First is for the team to do that investigation and learning informally during their slack time. This assumes the Developers are allowing themselves slack time—by not forecasting to 100 percent of their capacity.

Another idea is to perform a spike, which is another word for a technical investigation, proof of concept (POC), or an experiment, the outcome of which is to gain enough knowledge to be able to give the team some confidence in their plan and their estimate. Ultimately, Scrum is about learning from data derived from experiments—so the spike concept fits right in. When you see the look of sheer panic on the faces of your teammates when discussing/estimating a new PBI, it may be time to perform a spike.

Most spikes are small and executed as needed throughout the Sprint. In fact, I wouldn’t even call them a spike. They are just part of development. Some Scrum practitioners call them spike tasks (as opposed to larger spike stories). If a Developer needs to clarify a technical issue, and another team member cannot help, the Developer can create a quick spike instead. Timeboxing should always be used to keep spikes as small as possible and to help maintain focus. The Developers can decide the criteria for if/when to track a spike as a work item in Azure Boards. Transparency should be their guiding light.

Tip A spike is not the same thing as a tracer bullet. A tracer bullet is development that cuts vertically through the many layers of architecture. This is sometimes known as the practice of developing thin, vertical slices. Emergent architecture is the practice of continually developing in thin slices like this. Tracer bullets can be experimental in nature, like a spike.

When a spike is expected to take a large amount of time, or is required to be accomplished before the Developers are able to estimate a PBI, the Scrum Team should consider treating it like a PBI. Spikes then become part of the Sprint and should therefore be accounted for in Sprint Planning and be present in the Sprint Backlog. This means that the spike should be added to the Product Backlog first and forecast as part of the Sprint. Spikes can even have their own acceptance criteria to help specify the goal or outcome. A plan should be created and tracked, just like any other feature or bug fix. Because spikes don’t offer any direct value to the stakeholders (for example, users), there should always be other PBIs forecasted for that Sprint, even if just a few small ones, so that the product, Product Owner, and stakeholders can enjoy some increment of actual value every Sprint.

Smell It’s a smell when a spike takes the majority of the team the majority of the Sprint to accomplish. It’s a stench when it takes multiple Sprints. I guess it may be possible that the new architecture or technology is so alien that it really does require that much capacity to understand it to the point of being able to use it effectively. In my experience, however, good Developers aren’t caught flat-footed like this very often. New tools and technologies tend to be pretty similar to previous ones. Also, don’t let the Developers get into the habit of creating a spike for every PBI that they refine. True spikes should be rare.

Fixed-Price Contracts and Scrum

Scrum works well when the stakeholders trust the Scrum Team, the Product Owner trusts the Developers, and all are able to work together collaboratively. If the customer has had enough projects fail in the past, this trust won’t be there initially. In their minds, it will need to be replaced with a contractual relationship with the team instead. The customer’s hope is that the contract and its clauses and signatures will minimize the customer’s risk and provide a legal way of recovering costs if the team fails to deliver. From their perspective, they have only one shot at getting the product they want, so they want to define everything up front and then manage risk by putting a monetary limit and other constraints into the agreement.

The most common of these contract development agreements are known as fixed-price or (fixed-bid) contracts. They attempt to predict exactly the cost and the time at which the product that’s been specified by the customer will be delivered. The common misconception is that it is impossible to use Scrum on a fixed-price contract. In reality, Scrum handles this in the same way that any other process would. Everything the customer wants is detailed (minimally) and sized, generating an idea of the timeframe at which that scope can be delivered.

Here are the common challenges with fixed-priced contracts:

• ■   Price is the most important factor and is often driven by competition, not quality.

• ■   Requirements are vague, wrong, out of date, or missing.

• ■   Team-based estimation is impossible due to lack of empirical data.

• ■   No knowledgeable person (such as a Product Owner) exists.

• ■   The Scrum Team doesn’t have any incentive to spend time enlightening the (potential) customer about Scrum, or creating and refining a Product Backlog prior to signing a contract—although I have seen success when a team simply charges time and materials (T&M) to collaborate and create the Product Backlog, establishing trust during the process.

• ■   Quality is not defined, only assumed.

• ■   There is no Definition of Done, or even a basis for one.

• ■   Deadlines are artificial and often impossible.

• ■   Risks are not shared or are outright ignored.

Tip Beware of fixed-price, fixed-scope contracts. Scrum + fixed-price + fixed-scope don’t mix. This is the whole idea behind having a Product Backlog and an active Product Owner to order the PBIs. If the customer in a fixed-price contract wants to own both the date and the number of features, the only remaining variable is quality, and sacrificing quality never works out. Remember healthcare.gov?

Any fixed-price contract should be variable-scope. Not only does this fit better with the nature of complex work, it fits better with Scrum because the team can now apply a consistent Definition of Done and establish an uncompromising baseline of quality for all of the work it does. The team can then start using iterative, incremental development to begin delivering increments of working product every month or sooner. This model provides more value and less risk to both parties—but it is hard to conceptualize and agree to without knowing more about Scrum and the Scrum Team.

Perhaps a better name for a fixed-price contract would be simply a fixed-budget contract. The customer knows how much they want to spend, or at least what the ceiling is. This can be easily translated into the number of Sprints they are able to afford. For example, a customer with $300,000 to spend can afford a Scrum Team whose run rate is $30,000 per Sprint for 10 Sprints. By creating an ordered Product Backlog, the customer will get the most important/valuable features (according to them) before those 10 Sprints are up. Therefore, the ideal Scrum contract model should be fixed-budget, variable-scope.

Here are two rules to consider when you’re using Scrum for a fixed-price project:

• ■   The customer (via the Product Owner) can replace any item in the Product Backlog with another item of similar size, provided the Developers haven’t started working on it or completed it yet. If they have, there will be waste, and more importantly, one or more items may not make the cut before the budget runs out.

• ■   At any point in time, the customer (through the Product Owner) can say that they have enough functionality and effectively end the development effort, potentially saving money. Let any waterfallian contract top that!

It’s important for both the customer and the Scrum Team to share the risk. This means that the customer must work closely with a knowledgeable Product Owner or become the Product Owner—assuming that they know Scrum and the requirements of the Product Owner role. In either case, the customer can be directly involved in ordering the Product Backlog and determine the scope. This removes the risk of the Developers delivering the wrong features or not getting to those “must-have” features before the budget runs out. Some customers, after learning that they will be accountable for this, may decide to walk away and offer the work to a competitor. You should let this happen. In my opinion, this is the right thing to do, rather than running the risk of building the wrong product or a product of questionable quality and value. Remember healthcare.gov?

Common Dysfunctions

Leo Tolstoy told us that “happy families are all alike, but that every unhappy family is unhappy in its own way.” This is true of product development teams as well. A certain amount of dysfunction is going to exist, even in high-performance Professional Scrum Teams, and it will always be unique. This is because Scrum is about people, and people don’t behave like predictable machines.

Removing a dysfunctional behavior can be difficult. Identifying it in the first place can be very difficult, especially if you are in the middle of it or if you are the cause of it. Part of becoming good at Scrum is the ability to sniff out dysfunctional behavior. At first, this may be the ability to know when your team isn’t following the rules of Scrum, according the Scrum Guide. But that’s not enough. This is why—in this book—I’ve diligently pointed out many smells that you should be aware of.

It may seem like the Scrum Guide has an answer for everything, but it doesn’t. In fact, each version of the Scrum Guide seems to provide less guidance. The complex world of product development will sometimes put you and your team in a double-bind in the middle of two choices that conflict with each other. Your abilities should transcend from just knowing the rules to knowing (and applying) Scrum’s principles and values. Knowing the higher-level reasoning behind agile software development and why Scrum works allows you to identify and resolve such conflicts—and make leaner choices.

Teams new to Scrum may fumble when applying a practice for a given dysfunction. Their heads are down, executing that practice. They are in the shu stage. High-performance Professional Scrum Teams have moved beyond rote practices and think in principles. They are in the ha and ri stages. Their heads are up, looking for dysfunction and ways to eliminate waste and generate more value. It’s a state of mind, and it comes with experience. This section serves as a guidebook to the different types of dysfunction that can be found on a Scrum Team, and it offers ideas for removing them.

Note Shuhari is a Japanese martial art concept that describes the stages of learning toward mastery. The idea is that practitioners will pass through three stages of gaining knowledge. Shu is the beginning stage, where students follow the teachings of the master precisely. The master can be another team member, an external coach or trainer, a talking head on a training video, or the Scrum Guide. Shu-level students concentrate on how to do the task, without worrying too much about the underlying theory. Ha-level students begin to branch out and apply what they’ve learned. In doing so, they continue to learn the underlying principles and theory behind the practice. Ri-level students are now learning from their own practices rather than from other people. Mastery is just around the corner for them.

Not Getting Done

You would think that “done” is when a new feature or bug fix has been deployed and is running happily in production. I would agree. If that’s the status of your PBI, then you are definitely done with it. From Scrum’s point of view, however, this is not always the case. Done doesn’t necessarily mean that the PBI is in production but that it easily could be. This is the concept of being releasable (or potentially releasable, as some practitioners still say). In other words, in Scrum, Done can mean released or releasable.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it at a minimum. If no standards exist, the Scrum Team must create a Definition of Done appropriate for the product. Since the Definition of Done contains primarily development-related practices and standards, the Developers will probably have the most influence over what gets included. The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done. Individual Scrum Teams can have a more stringent Definition of Done, however. I cover this in Chapter 11, “Scaled Professional Scrum.”

What Done doesn’t mean is that the PBI has been coded but not yet tested. In Scrum, all development activities, including testing, must be finished before a PBI can be considered Done. It’s a dysfunction when the Developers are not able to complete their work according to the Definition of Done. Perhaps their definition is too stringent. Perhaps the Sprint length is too short. Perhaps the Sprint length is too long. Nothing focuses the Developers like knowing they have a Sprint Review coming up in a few days!

External dependencies are another huge cause of not getting done. An example would be having to wait for people outside of the Scrum Team to perform review, testing, audit, or sign-off. These might be users or customers performing user acceptance testing or managers who need to approve the work. It’s critical that only the Developers do the work—all of the work—to make a PBI Done. Not only will this lower the risk of not getting Done, but it’s also not Scrum until this is the case. Retrospect hard on these impediments until they are removed.

Smell It’s a smell when I hear a team using the terms done done or really done. Historically, these terms have meant that both coding and testing had been completed, which implies that there was a done state where just the coding was finished. In Scrum there is only Done—as defined by the Definition of Done—and the team is either there or they aren’t. It is a simple Boolean state.

In Chapter 1, “Professional Scrum,” I mentioned that the Definition of Done is an auditable checklist that each PBI must go through before it is considered Done. When each item in that definition is “checked off,” the PBI is Done and releasable. Some Scrum Teams include an item in the definition verifying the Product Owner’s acceptance. Other teams don’t and just understand that it’s simply a part of Scrum’s workflow for being done. Either approach is fine, as long as it is uniformly applied, understood by the entire Scrum Team, and never undermined. Personally, I would strive for the Product Owner’s “delight” or “elation” over just their “acceptance.”

Tip There are times that the team will not get done. It can be hard to prevent this from happening. It is important not to make it a habit by forecasting too much work. It is also important to craft a reasonable Sprint Goal during Sprint Planning. Having a Sprint Goal is important because, even if some of the forecasted PBIs aren’t completed, at least the goal was met and stakeholders will be able to inspect something of value. The Scrum Team should make good use of Sprint Planning by analyzing all of the inputs, checking capacity and past performance (such as velocity or Throughput), and forecasting a comfortable amount of work each Sprint.

Flaccid Scrum

In January 2009, Martin Fowler wrote a blog post titled “Flaccid Scrum.” Just as the name implies, his observations of many teams doing Scrum were that they were doing poorly. His typical observation would include a team that wanted to use an agile process, so they picked Scrum. The team adopted the Scrum practices, and maybe even the principles. After a while, progress slowed because the codebase became a mess and the team found itself drowning in technical debt. You can read Martin Fowler’s article here: http://martinfowler.com/bliki/FlaccidScrum.html.

The fact that these teams were using Scrum was orthogonal to the root cause of the problem. It was just another example of teams and organizations considering Scrum a silver bullet. Scrum is simply a framework for planning and managing complex work. It says nothing about specific development practices exercised within, other than the generic statements relating to improvement. In other words, the Scrum framework allows any number of practices to be used, regardless of how dysfunctional they may be.

I surmise that the products that these teams were developing suffered low quality because the Developers were not inspecting, not adapting, or both. Perhaps the Scrum Value of openness was deficient as well. Remember that Scrum has built-in opportunities to inspect and adapt, at both the product and the process level. The fact that technical debt was building up to critical levels was because the teams either didn’t know (weren’t inspecting) or didn’t care (weren’t adapting).

Note I’ve met with many such teams who love to throw around the Scrum terms Sprint, Scrum Master, Product Backlog, and so on. But when it came to being able to deliver business value within a timebox, they couldn’t do it. It seems as though they were using the Scrum nouns but not doing the Scrum verbs. This type of behavior is known as “zombie Scrum,” which is Scrum without the beating heart of working product. Other names that refer to this kind of Scrum are mechanical Scrum, dark Scrum, Scrum in name only, and ScrumBut. There are nuanced differences between these, but they all relate to Scrum being practiced in a dysfunctional way.

To fight flaccid Scrum, the Developers need to inspect and adapt their technical practices. This is true especially if there is a lot of technical dysfunction and technical debt present. During the Sprint Retrospective, the team should inspect its current practices and, if improvement is required, agree to adopt, continue using, or abandon the practice in question. They can also take this opportunity to ratchet up their Definition of Done and include more stringent criteria for higher quality. Most importantly, in the next Sprint, they can adapt by executing these improvements.

Tip The Professional Scrum Developer (PSD) program was a direct response to the problem of flaccid Scrum. The program consists of a training course, assessment, certification, and a community developed for the most neglected role in Scrum: the Developer. The PSD course was developed in cooperation between Microsoft, Scrum.org, and Accentient. You can find out more by visiting www.scrum.org/psd.

Not Inspecting, Not Adapting

Flaccid Scrum came about because of many reasons. Teams were uneducated. Teams didn’t have a Definition of Done, or they didn’t stick with it, or they didn’t try to improve it. Teams weren’t able to deliver business value in a single Sprint. Teams weren’t inspecting. Teams weren’t adapting.

Scrum is based on empiricism, which means that the team members make decisions based on what is. These professionals must frequently inspect Scrum artifacts and their progress toward goals (product, release, Sprint, etc.) to detect any undesirable variances. Good decisions can’t be made without data. Conversely, meaningful data is useless unless it is acted upon. Not doing either is definitely a dysfunction.

Tip If I want to know how well a Scrum Team is inspecting and adapting, I will ask about their Sprint Retrospectives. In my experience, the Sprint Retrospective is the first to suffer when times get rough. Sure, the team may meet and discuss stuff, but they may not act on their findings. I contend that “rough times” can be translated as “We were super busy,” “We didn’t like what we discovered,” or “We didn’t want to improve.” Another inspection—one intended for the Developers—is to review their automated regression test coverage. This is a key indicator of how well they are improving their technical excellence.

For example, a Scrum Team may be very diligent about scheduling and attending their Sprint Retrospective. They may have rich conversations and discuss the high and low points of the Sprint. They may even identify things to do differently in the future. Multiple team members capture this information and then do nothing with it. They have inspected, but not adapted. This is belief in magic. This is flaccid Scrum.

Tip Anything the Scrum Team tries to do differently in the next Sprint should be visible and transparent. There are several strategies for doing this. Some teams use a “retrospective backlog” or “improvement backlog,” whereas others add tasks directly to the next Sprint’s Backlog to represent the work and time needed to adapt their practices. One option is to further customize the Professional Scrum process, adding a new Improvement work item type, as you can see in Figure 10-5. I spent some time in Chapter 3 going over how to create a custom Professional Scrum process, inherited from the default Scrum process.

FIGURE 10-5 It’s useful and encouraging to track planned improvements and not just impediments.

Smell It’s a smell when I see nobody taking notes during the Sprint Retrospective. Does the team not have anything interesting to discuss and record? Maybe they have nothing that can be fixed, and thus no action items. That is sad. It is also untrue. With the organizations I’ve worked with, every individual and team could improve. This flaccid behavior should be corrected. In the meantime, and at the very least, the Scrum Master should be recording any inspections and then ensuring that the appropriate experiments are conducted and adaptations are made. It’s also a smell when I hear the same items coming up repeatedly. This is a failure to adapt.

On the other hand, formal inspection should not occur so frequently that it gets in the way of the work. In order to minimize this, each Scrum event is an opportunity for inspection and adaptation:

• ■   Sprint Planning   The Product Backlog, Product Goal, Increment, Definition of Done, and past performance are inspected, and the Sprint Backlog is adapted.

• ■   Daily Scrum   The Developers’ progress toward the Sprint Goal is inspected, and their plan for the next 24 hours is adapted.

• ■   Sprint Review   The Increment is inspected, and the Product Backlog is adapted.

• ■   Sprint Retrospective   The process, practices, Definition of Done, and definition of workflow are inspected and adapted (during the next Sprint).

Developer Challenges

It takes time for the Developers to be able to self-manage, even with the support of the organization. Teams that come from a more formal, waterfallian background are used to the relative safety of the different stages. Hiding behind (the wrong) requirements or in front of (the yet-to-be-run) tests provides a level of safety and cover. Moving to an attitude of transparency—understanding that everybody is on the same team, working toward the same goals, and sharing in the same successes and failures—can take time.

As I’ve said before, Scrum is about people. These people work together as a team communicating, listening, complementing each other’s skills, sharing objectives, and solving problems together. There must be compassion and respect for each other, as well as trust. These attributes will develop and improve over time. Professional Scrum Developers continually balance the three raw ingredients: people, process, and technology. You can see this in Figure 10-6.

FIGURE 10-6 Achieving high-performance Scrum is a continuous balancing act.

People exhibit different behaviors depending on the context of a situation. There is the normal behavior: how team members usually see one another. There is problem-solving behavior: the team members are fully engaged mentally and getting stuff done. There is also stress behavior: quite different from the others and often harder for the rest of the team to deal with. During any given Sprint, each of these behaviors can be observable.

Scrum Teams need to learn to deal effectively with ambiguity. Most of the time, the team won’t have all the answers, or even many answers. Effectiveness in the face of ambiguity is a measure of growth. Teams will find themselves in unusual circumstances that cannot be solved by thinking at the practice level; rather, a problem can be solved only by abstracting to the principle level. It’s up to the individuals to make judgments and not just copy and paste random bits of practice.

In addition to dealing with ambiguity, a number of other challenges face Developers. Here is a list of dysfunctions—sometimes expressed as “weasel words” —that may be found in any given team of Developers:

• ■   I don’t have all the requirements   A major theme in Scrum is the ability for the Developers to self-manage and get the job done. If there is missing information, fix that by getting the answers. If you want to add functionality over and above what the Product Owner is asking for, don’t. Remember, the Product Owner owns the what, and the Developers own the how. Collaborating with the Product Owner and stakeholders can help obtain those missing “requirements.”

• ■   I tell other people what to do   Each Developer needs to be able to self-manage. This means that nobody, not a manager, not the Product Owner, and not even the Scrum Master can order a Developer to work on a particular task or to do a task in a particular way. Work is never assigned in Scrum. If you have a command-and-control personality, perhaps you need to excuse yourself from the team for a while so that they can learn these skills in your stead.

• ■   I’m quiet and don’t like to converse with others   Effective collaboration requires all parties to communicate. This is more than just actively listening—it’s also actively communicating and sharing ideas. Everyone on the team is creative and has ideas to share.

• ■   I monopolize the conversation   Stop doing that. Use active listening skills to improve your ability to communicate and collaborate with others. Your teammates will thank you.

• ■   I’m a coder, not a tester or I’m a tester, not a coder   In Scrum, everyone is a “Developer” regardless of what HR or their business card says or what activity they are working at that moment. Besides, most automated tests are written in code—so you can be both!

• ■   I’m not to blame; another Developer broke it   In Scrum, the whole team succeeds or fails. If something broke, it’s because the team broke it. The team will fix it. Focus on being a team player.

• ■   I’ll let the Scrum Master remove the impediment   If you can remove the impediment yourself, do it. If you cannot, or if you can provide more value by doing something else (such as developing product), consider asking the Scrum Master for help.

• ■   I write great code by myself   That’s nice to know. Having another Developer review your code or pairing with another Developer isn’t about you or your code. It can be a learning experience for others, as well as a way to improve the quality of the product. It also helps hedge against the event where you are hit by a bus or decide to quit your job because you’ve won the lottery.

• ■   I’ll work evenings and weekends to get this done   Thank you, but that sounds like an unsustainable pace. Typically, this smell is due to time management or over-forecasting dysfunctions. During the next Sprint Retrospective, the team should discuss this and find an alternative approach to reaching its goals, such as forecasting less work in the next Sprint. Slack time is good for experimenting and learning.

• ■   I can goof off because others will do my work   Every day, all Developers meet for the Daily Scrum. During this time, each Developer clarifies their plan for the next 24 hours. If, for example, by the third day, a Developer is still working on the same task, the others should take notice. The self-managing team can then find an appropriate solution, such as helping that Developer while explaining the Scrum Value of openness to them.

• ■   Nobody on our team has that skill set   This may be true, especially as a product delves into new markets requiring new technologies. The reality is that Developers need to acquire the necessary skills. Attend training, watch some videos, perform some experiments, or learn in some other way. Adding a new Developer to the team is an option but can be costly in terms of onboarding and other interruptions. Be sure to account for this disruption at future Sprint Plannings, and add any large spikes to the Product Backlog if necessary.

• ■   I’ll give it to the testers at the end of the Sprint   First of all, there are no “testers” in Scrum, only Developers. Some Developers will focus on coding tasks and others on testing tasks, but this is not written in stone. For a PBI to be Done, it needs to be tested as well. Waiting until the end of the Sprint to test will increase the risk of not getting Done. If you have capacity, you can do the testing work yourself. Be T-shaped.

• ■   Nothing is blocking me   These are commonly heard words during a Daily Scrum. But they do not always reflect reality. Developers need to learn that transparency and openness start within themselves. If there is an impediment or even the possibility of an impediment blocking some work, be sure to let others know, regardless of whether or not you have other things to work on. Identifying actual or possible impediments is not whining, and it is not a sign of weakness. In fact, it is quite the opposite. Identifying impediments is about transparency and creating a Professional Scrum Team.

Measuring Performance

The performance of the team of Developers should be measured by what it is able to develop. In other words, rate the team by its ability to turn PBIs into Increments of functionality that are actually released. This can be measured for a specific Sprint or range of Sprints (for example, a release).

Velocity is the measure of how many PBIs (or points) the team is able to deliver each Sprint. This measure can then be divided by the cost of the team to develop that Increment. For example, if it costs $20,000/Sprint to run the Scrum Team and the outcome of the last five Sprints is a release that totaled 100 story points, then the performance of the Scrum Team is $1,000/story point.

Tip From the perspective of the business, velocity is not a good metric on which to measure performance. If the Product Owner tracks business value for each PBI—which they should be doing—this provides a better measure than just the number of PBIs or the sum of their story points. Whether the business value is specified in a numeric range, income/profit, or some specific scale, when this number is expressed over a monetary amount, it will tell the business exactly how much value is being returned on their investment (ROI). Tracking ROI per PBI helps the Product Owner and organization focus on business value for investing and budgeting. To continue with the previous example, the Product Owner could compute how much value was delivered for the $100k. If the PBIs in that release totaled 160 units of business value, then the performance of the Scrum Team is $625/unit of business value.

The performance of individual Developers should not be measured. The team is self-managing and operates as a unit, not as a group of individuals. For a given Sprint or release, some Developers may be a lot more heads-down than others. As such, it may appear to outsiders that these individuals are “working harder” and more worthy of praise or bonuses. Other Developers, those not at a keyboard, may actually be working harder while coaching, mentoring, or designing. Invisible measurements like this are hard to measure and can be missed. A better approach is to rate the performance of the team as a whole and according to the value that they deliver. If it needs to go beyond that, let the team decide who the performers are.

The best way for a manager to see and learn what’s really going on within a team is to sit directly with the Developers. Decisions based on indirect information such as dashboards and reports are likely not to be the best decisions. Decisions based on actually going and seeing and understanding the real situation at hand are likely to be much more informed. This practice is called a “gemba walk” or simply “go see.”

Working with a Challenging Product Owner

The Product Owner is responsible for maximizing the value of the product and, thus, the work of the Developers. This is a lot of responsibility for a single person, making this the hardest role in Scrum in my opinion. Needless to say, a good Professional Scrum Master can find at least one or two dysfunctions for a Product Owner to improve upon.

One of the biggest dysfunctions a Product Owner can possess is not knowing their role. They must reflect the real value and priorities of the business, customer, or user with respect to the product. This is both the biggest responsibility and the biggest potential risk of the role. The Product Owner is one person, not a committee. The desires of a committee, however, may be represented by the Product Owner.

Note Organizations often struggle to find viable Product Owner candidates among their existing employees. People with technical backgrounds are typically better suited to be a Developer, because they like to get involved with how things are developed rather than what should be developed. Employees with management backgrounds might be inclined to practice traditional project management techniques, even instilling command-and-control practices. Candidates with strong Scrum knowledge typically gravitate toward being the Scrum Master. These are, of course, generalizations.

Successful Product Owners tend to have product management and even marketing backgrounds. They understand terms like ROI, P&L, market segment, and sales channel. Maybe they were even a user of the product at one time. When no such candidates exist, I’ve seen some organizations advertise the position of Product Owner publicly. It sounds weird, but by bringing in someone off the street with the knowledge of what a Product Owner should do, but absent the knowledge of organizational politics and the “old way” of doing things in the organization, is often a recipe for success. They just need to learn the product and the desires of the customer and users in order to succeed. They must also be given the appropriate authority.

Being able to negotiate the politics of an organization, its committees, and the users can be an exhaustive, full-time job. For the Product Owner to succeed, the entire organization must respect their decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog as well as the functionality of the product. No one is allowed to tell the Developers to work from a different set of requirements, and the Developers aren’t allowed to act on what anyone else says.

Here is a list of other challenges you might encounter when working with a Product Owner:

• ■   Injecting their own version of Scrum   There is only one version of Scrum, and it’s documented in the Scrum Guide. Implementing anything else risks upsetting the established flow. Any allegiance to old waterfallian habits—even if they are disguised under new Scrum terminology—must go. Understand that mental muscle memory takes time to fade.

• ■   Insufficient acceptance criteria   A good PBI doesn’t just stop at a title and description. The Product Owner, through conversations with stakeholders, should evolve the PBI and define what success looks like in the form of acceptance criteria. These should be testable—maybe even written as executable specifications.

• ■   Absent or doesn’t interact with the team   In order to maximize the work of the Developers, the Product Owner must interact and collaborate. This is especially true during Sprint Planning, Sprint Review, and Sprint Retrospectives, as well as during Product Backlog refinement. The Product Owner should also be regularly available during the Sprint to answer questions, clarify details, make introductions, review work, and provide feedback. For a Product Owner, a good rule of thumb is to spend 1/3 of their time with the product, 1/3 of their time with the stakeholders, and 1/3 of their time with the Developers. These ratios will change with new/challenging products, stakeholders, and Developers.

• ■   Disrupts the team   Whether it’s to introduce a new piece of work during the Sprint (scope creep) or just wandering into the team room or Zoom meeting and asking how things are going, these intrusions can interrupt the flow and kill focus. The Scrum Master should get involved and help the Product Owner understand this.

• ■   Provides the solutions   The Product Owner must allow the Developers to self-manage and come up with their own solutions. So long as it is fit-for-purpose, meets the acceptance criteria, and abides by the Definition of Done, any solution should be acceptable.

• ■   Blocks Developers from talking with stakeholders   The Product Owner is not omniscient. There will be many opportunities for the Developers to build a better product by collaborating directly with the stakeholders (such as customers and users) during the Sprint. The Product Owner should not act as a gatekeeper for these conversations.

• ■   Indecisiveness   The Product Owner has the authority to make decisions pertaining to the product. This includes everything from determining the value of a PBI, to ordering the Product Backlog, to changing the scope of a Sprint, and even canceling a Sprint. The Scrum Master can help the Product Owner understand the trade-offs of these various decisions, but the decisions still have to be made.

• ■   Not being prepared   This common dysfunction is especially risky with regard to Product Owners. The plans of multiple people (the Developers) depend on the decisions made by a single person (the Product Owner). If the Product Owner is not prepared, much waste can be generated and morale can suffer. Regular Product Backlog refinement can help the Product Backlog—and Product Owner—be prepared for Sprint Planning. Sometimes a definition of “ready” can be useful, too.

• ■   Command-and-control behavior   In Scrum, the Product Owner is not the “boss” in the traditional sense. It is acceptable for the Developers to say “no”—especially when the Product Owner is asking them to do something that is out of bounds for their role or the rules of Scrum. Examples might include generating technical debt, violating the Definition of Done, or releasing undone work. The Scrum Master can be called in to referee if necessary.

• ■   Expects a commitment, not a forecast   An important change was made in the Scrum Guide in 2011. The Developers forecast the work that they believe can be completed (according to the Definition of Done) during the Sprint, but they don’t commit to it. If a Product Owner expects a commitment, such as assuming the Developers will work nights and weekends until the Sprint Backlog is complete, that is an unhealthy, dysfunctional behavior. It ignores the reality of complex work and sets the expectation for an unsustainable pace. The Product Owner must learn the difference between a forecast and a commitment—which any Professional Scrum Master can help explain. For more information, read fellow Professional Scrum Trainer Barry Overeem’s explanation here: www.scrum.org/resources/blog/commitment-versus-forecast.

• ■   Multiple Product Owners   The Product Owner is one person, not a committee. The Developers, as well as the stakeholders, should have a “single wringable neck” (or “one throat to choke”)—metaphorically speaking. Having multiple Product Owners is confusing to everybody. Pick one, and the others become stakeholders who help the Product Owner create PBIs and order the Product Backlog. Alternatively, the Scrum Team could probably use more Developers.

• ■   Multiple stakeholders, but no true Product Owner   People often confuse the role of Product Owner with that of a business stakeholder. Just because someone has an influence on the product, or the business that uses the product, doesn’t make that person a Product Owner. The Product Owner is a specific role—with authority—defined in Scrum. The Product Owner works closely and collaboratively with stakeholders, as well as the rest of the Scrum Team to maximize the value of the product.

• ■   The Developers maintain the Product Backlog   Developers typically do not have the vision and insight into the needs of the stakeholders to evolve and maintain the Product Backlog adequately. Although there are exceptions, Developers tend to be better at solving technical problems and creating product. This is why the Product Owner needs to be present and accountable for maximizing ROI in the product—which is done through the content and order of the items in the Product Backlog. There may be times that the Developers get involved, such as helping the Product Owner understand how technical dependencies affect delivery order, but they should not be handed the Product Backlog to take over management. The Product Owner is responsible for maintaining the content and order of the Product Backlog, and passing that task along to others smells like an absent Product Owner.

• ■   Acting as a Developer   Product Owners sometimes come up through an organization’s technical ranks. While developing the product, one of the team may have learned everything there is to know about the product and its use and ended up becoming its Product Owner. This increases the chances that the person will become involved with how it should be developed, when they should remain focused on what to develop. That said, having a Product Owner also be a Developer—which is allowed in Scrum—is sometimes unavoidable, especially for smaller teams such as startups.

The Product Owner is a full member of the Scrum Team and, as such, should be present at all Scrum events, with the possible exception of the Daily Scrum. The purpose of the Daily Scrum is for the Developers to create a plan for the next 24 hours. The Product Owner shouldn’t have any input on the plan, nor do they need to know about those plans once they are made. The Product Owner, however, should be available to the Developers as they work. Being in close proximity and ready to collaborate in person as needed is a recipe for a successful product. Keep in mind that the Product Owner also needs to work with stakeholders during these same hours, so availability may be limited. Collocation or “office hours” may be a solution.

Smell It’s a smell when I meet a Scrum Team who still goes by their old titles. When I’m introduced to the Scrum Master, and she tells me her name is Audre and she’s the director of IT, I get confused. The rest of her teammates might get confused. too. Remember, in Scrum, there are only the Product Owner, Scrum Master, and Developer roles. What you used to be called or your HR designation isn’t relevant anymore.

Working with Challenging Stakeholders

Stakeholders are not an official role in Scrum, but they exist and can be challenging to work with. Remember that a stakeholder is any person who has a direct or indirect interest in the work of the Scrum Team. They may be a customer, a user, a domain expert, a manager, an auditor, an executive, or a member of the public. Unless you are the Product Owner, interactions with stakeholders may ebb and flow. The only time Developers are guaranteed to interact with stakeholders is during the Sprint Review.

Stakeholders may or may not know about Scrum. And what they do know, may not be accurate. They may have read something, taken some training, or watched some videos online—none of which guarantees that what they know is Scrum according to the Scrum Guide. Some stakeholders may think Scrum is a “silver bullet” and just by using the nouns during conversations and meetings, all risk will be removed and value will flow quickly and perfectly. This is magical thinking.

It’s the responsibility of the Scrum Master to squash this illusion and educate the uneducated that Scrum’s success depends on empiricism and the commitment of the people practicing it. Stakeholders are welcome, and encouraged, to watch the great experiment take place, interacting where and when appropriate.

Note Scrum was not designed to keep stakeholders from interacting with the Developer. On the contrary, Scrum is intended to bring the two camps—business and technical—closer together, just in a more structured and productive way. For example, the Sprint Review allows stakeholders to inspect working product and provide rich feedback, which can be captured in the Product Backlog. Most stakeholders are ecstatic that there is now a process that actually allows them to see Done, working product every few weeks. Stakeholders typically welcome this transparency.

Here is a list of challenges you might encounter when interacting with a stakeholder:

• ■   Doesn’t understand the Definition of Done   Since stakeholders do not necessarily know Scrum, they may not understand why something “they saw running in a browser yesterday” isn’t done and able to be properly inspected during Sprint Review. You, or the Scrum Master, can explain how the Definition of Done ensures an uncompromising level of quality. This explanation should be provided in business terms familiar to the stakeholder. For example, instead of saying, “Load testing has not been completed,” you could say, “We are still unsure how the application performs with more than 10 concurrent users.”

• ■   Doesn’t provide feedback   Some stakeholders are just not that interested in the product. They may be paying for it, or managing the employees who will be using it, but they are otherwise indifferent. If it won’t hurt the long-term prospects of the product, consider not inviting them to future Sprint Reviews, or at least inviting other, more interested, parties. Whenever possible, invite a few key users. They tend to be passionate about what the team is doing and provide valuable feedback. Remember, the purpose of the Sprint Review is to obtain stakeholder feedback.

• ■   Injects their own version of Scrum   There is only one version of Scrum, and it’s documented in the Scrum Guide. Anything else risks upsetting the established flow.

• ■   Absent or doesn’t interact with the team   In order to maximize the work of the Developers, stakeholders (especially domain experts) must be available periodically to help answer questions and provide feedback. This is the minimum bar. For an awesome product, stakeholders should consider collaborating directly with the Developers. This means being open to pairing with a Developer for a period of time as they design, code, and validate functionality.

• ■   Disrupts the team   Stakeholders, by definition, have an interest in what the Scrum Team is doing. They may wander into the team room or Zoom meeting and ask how things are going. These intrusions can interrupt flow and kill focus. The Scrum Master should get involved. Stakeholders shouldn’t attend the Sprint Retrospective.

• ■   Provides the solutions   The stakeholders are free to work with the Product Owner to clarify what is to be developed. The Developers, however, are self-managing and come up with their own solutions.

• ■   Not able to say “no” to a stakeholder   In Scrum, the stakeholder is not your “boss” in the traditional sense. Unfortunately, they may be the owner of the company, and absolutely your boss outside of the context of Scrum. In this situation, the Scrum Value of courage only goes so far and the Scrum Master may need to join the conversation.

• ■   Expects a commitment, not a forecast   Stakeholders must acknowledge the reality of complex product development and allow the Developers to forecast the work they can do in a Sprint—not force them to commit to it. The Scrum Master can explain the difference and also the fact that what the Developers do is hard.

• ■   Acts as a manager   The Scrum Team is self-managing. Nobody, including stakeholders, can tell the team how to do their work, or what they should work on next. That said, stakeholders can be very influential as to what should be worked on next. This kind of feedback is very pertinent, should involve the Product Owner, and should be manifested by the order of PBIs in the Product Backlog.

• ■   Acts as a Developer   Some stakeholders may be a developer from another team or another decade. Be cautious of them getting too involved in the development your team is doing. They can easily become a distraction. If, on the other hand, they have the skills you need and the capacity to help, have them join your Scrum Team—even if only as a part-time Developer.

• ■   Acts as an insurgent   Some stakeholders, for whatever reason, are resistant to change and just anti-Scrum. Maybe they tried it at a previous organization and were unsuccessful. Maybe they prefer waterfall or Kanban. Maybe they hate rugby. Sometimes such a person is necessary to support the successful adoption of Scrum. Hopefully the Scrum Master can help educate and open their eyes.

Working with a Challenging Scrum Master

The Scrum Master is responsible for ensuring that Scrum is understood and enacted. Scrum Masters do this by advising, coaching, and mentoring the Scrum Team members so that they adhere to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team and a facilitator who supports the team in learning self-management, and understanding and adopting the rules of Scrum and the Scrum Values.

A good Scrum Master brings value to the Scrum Team, and the organization, by helping both adopt and progress toward Professional Scrum in a realistic way. By applying what they know, the Scrum Master can help the team build and deliver product that is of higher quality and value. This is done by maximizing the benefits produced by Scrum. Professional Scrum Masters should be putting themselves out of a job by teaching the team to identify and solve their own problems.

Tip The key to finding a good Scrum Master is seeing them in action. Let the candidate attend a Daily Scrum and tell you what they observe. This way, you can see if they have a nose for sniffing out dysfunction. Their knowledge of the rules of Scrum, as well as their perception of the team’s behavior and level of collaboration, should speak volumes about experience and capability.

Beyond supporting the Scrum Team, Scrum Masters can also be responsible for educating the organization and leading the effort to adopt Scrum. This means that they may play the role of mentor, coach, consultant, or even trainer. It also means that the Scrum Master is a walking Scrum salesperson, always pointing out the empirical benefits of adopting Scrum to new people and potential teams. Your Scrum Master should be able to articulate why Scrum works and is healthy for the organization, even to the loudest critics and detractors.

Here is a list of challenges you might encounter when working with a Scrum Master:

• ■   Doesn’t know Scrum   This is a deal breaker. If there is one person on the Scrum Team, or in the organization, who must know Scrum, it’s the Scrum Master. Inform management that the Scrum Master needs more training than just reading the Scrum Guide. If they don’t know about the Scrum Guide, I think you’ve found the problem. That may sound silly, but I recently helped an organization fill a Scrum Master role. Of the four candidates I interviewed, only one knew about the Scrum Guide. Consider sending them to a Scrum.org class (www.scrum.org/courses). Experience will come with time, but since it’s required on day one, hire an experienced Scrum Master, even if only temporarily.

• ■   Doesn’t enforce the rules   A Scrum Master is a coach, but also a referee. They should be confident in “throwing a flag” or showing someone a “yellow card” if the situation calls for it. The rules of Scrum have been fine-tuned over years of use. Those rules only work when they are followed. That said, there is room for adaptation once the core principles are embedded in the organization.

  

  Tip It may be challenging for a Scrum Master to enforce the rules. I tend to think of Scrum Masters as being firm and resolved, but in practice, this type of Scrum Master can sometimes create an adversarial environment. As an alternative, a Scrum Master should coach their team members to follow the rules of Scrum. If the team wants to step outside the rules of Scrum, the Scrum Master should use assertive questioning and dialogue to probe and discuss. If, after the discussion the team still wants to break the rules, the Scrum Master may want to allow it as a learning experience. Then, during the Sprint Retrospective, the Scrum Master should help the team inspect the results from not following the rules.

• ■   Focuses too much on rules and practices   A Scrum Master should enforce the rules, but focusing too much on the rules and practices is a form of zombie Scrum and can create a “cargo cult” mentality. In this dysfunction, the team executes the practices, but doesn’t reap any benefits. A Scrum Master should always make sure that the team is getting the most out the Scrum practices and rules. For more information on cargo cult, you can read up on it here: https://en.wikipedia.org/wiki/Cargo_cult.

• ■   Doesn’t act as a firewall   The Scrum Master is the protector of the team’s focus. As such, they should block any such interruptions—in any way possible. This might include going to meetings in place of the rest of the team, tracking and providing actual hours worked or other wasteful but “required” metrics to the PMO, or educating others in the organization on how to interpret a burndown chart. A Scrum Master should respect the Developers’ flow, and do whatever is necessary to protect it.

• ■   Acts as a manager   The Developers are self-managing. Nobody, including the Scrum Master, can tell them how to do their work. The Scrum Master should avoid even suggesting how a team member does their work or what to work on next. The exception to this is when the Scrum Master is asked for help, or if one or more Developers exhibit dysfunctional behavior or has otherwise become an impediment. The Scrum Master should have the authority to implement and enact the rules of Scrum, including removing such impediments. I’ll leave it at that.

• ■   Absent Scrum Master   The Scrum Master is a servant-leader and, as such, should be collocated with the team, ready to help. The only time the Scrum Master should be unavailable is when they are away educating the organization, removing an impediment, or taking a (much-deserved) vacation.

• ■   Doesn’t manage conflicts   Since Scrum is about people, Scrum Teams will inevitably experience conflicts. Simple conflicts can (and should) be handled by the people involved. More complex conflicts may require the Scrum Master to become involved. If a Scrum Master is hesitant or doesn’t have the social skills required to manage such conflicts, this is a dysfunction.

• ■   Settles for the status quo   A Scrum Master should be hungry for improvement. Just as a teacher gets excited when students are learning new things and applying what they’ve learned, so should a Scrum Master thrive on seeing the Scrum Team living the Scrum Values and improving. Professional Scrum Masters are constantly looking for new practices and techniques to increase empiricism and self-management.

• ■   Poor communication   This is more than just the Scrum Master not being able to communicate clearly, but allowing communication dysfunctions to fester and grow in the team. This type of behavior can infect other team members—especially if they see the Scrum Master partaking. A Professional Scrum Master knows how to teach and foster good communication techniques in the Scrum Team. This includes teaching topics such as active listening and the Scrum Value of respect.

• ■   Has a day job   Any additional role that a Scrum Master occupies is a conflict that can cause difficulty, especially for newly formed teams. Sometimes this is unavoidable. Smaller teams or startups may require dual roles. One dual role—Scrum Master and Project Manager—should be avoided.

• ■   Doesn’t deal with impediments   A good Scrum Master will give the team the opportunity to remove their own impediments and then learn from the experience. A dysfunctional Scrum Master will allow impediments to linger. If the Scrum Master can’t directly remove the impediment, they should at least find someone in the organization who can.

• ■   Acts like the team’s mother   Not that there’s anything wrong with mothers, but the “mom” Scrum Master type can also be a dysfunction. These Scrum Masters deal with the secretarial and nanny tasks. Examples might include meeting scheduler, Azure Boards typist, Sprint Backlog and burndown updater, stopwatch handler, flow metric gatherer, looking disappointed when you’re late to the Daily Scrum, and so on. New and uneducated Scrum Teams might think that this is what the Scrum Master does. I only hope somebody in the organization is aware of this dysfunction, since the Scrum Master probably won’t be capable of recognizing it themselves.

• ■   Acts as a Developer   In a lot of ways, the Scrum Master is like a firefighter. They sit, waiting to be called upon to answer a question or remove an impediment. Having the Scrum Master involved in the actual development, taking on tasks, tends to distract from the job of helping the team and organization understand and follow the rules of Scrum. Sometimes this is unavoidable—especially for smaller teams and startups. If one person is playing both roles, make sure that they give priority to the Scrum Master duties over the Developer duties.

Changing Scrum

Scrum is simply a set of rules put forth in the Scrum Guide. This makes it comparable to the game of chess. Chess has rules, too. One rule in chess is that a player is allowed to have only one king on the board. Scrum’s rules dictate only having one Product Owner. There are many other comparisons, but you get the idea. When you sit down to play chess, you either play by the rules or you don’t. Same with Scrum. If you want a short-term win, you can cheat and have three kings, but you won’t learn how to play the game properly or get good at it. Learning how the chess pieces move is fairly easy, just like learning the rules of Scrum, but mastering chess (and Scrum) is difficult and takes a long time and a lot of practice.

Professional Scrum Masters know how to play the game of Scrum properly. Because of that, they can easily spot those who cheat. To avoid the embarrassment of being called out by a Professional Scrum Master, don’t cheat. Even if you could get away with it, why would you? You will improve only if you don’t cheat.

The rules of Scrum should be considered immutable. An organization or team should not change them. You should inspect and adapt your behaviors within those rules and improve accordingly. Every Scrum role, artifact, event, and rule is designed to provide the desired benefits and address predictable recurring problems. Feel safe. Scrum will not fail you.

Old Waterfallian Habits

Waterfall development is the name given to a more traditional, sequential design approach to development where one phase is completed before moving to the next. Design is done before programming. Programming is done before testing. And so on. Each phase is performed as though you are not coming back to it. Maximum attention is given in getting it right the first time. This approach to developing complex products—such as software—is very risky, more costly, and less efficient than Scrum.

Unfortunately, waterfall has been in existence for over 60 years. Many technical professionals and managers are familiar with it and have it imprinted in their mental muscle memory. When these people are introduced to Scrum, they may feel compelled to change Scrum, molding it into something they are more familiar with.

Here are some waterfallian habits—or at least smells—that should be inspected, adapted, and avoided in Scrum, along with the reasons why:

• ■   Running longer Sprints (more than one month)   Sprint lengths of one month or less provide focus and reduce risk. Longer Sprints increase risk exponentially, even if they feel more comfortable.

• ■   Defining big requirements up front   Time spent defining detailed requirements, and especially how they should be implemented (specifications), is wasted when development of those items is delayed or skipped altogether because of the Product Owner’s decisions.

• ■   Establishing separate teams to code and test   Cross-functional teams are more efficient because they are able to work together with fewer handoffs. Only PBIs that meet the Definition of Done (which includes testing) are releasable. This lessens the exponential buildup of work toward the end of the release.

• ■   Running infrastructure and architecture Sprints   Every Sprint must generate an Increment containing business value. This keeps the Developers focused on what’s best for the customer or user. Emergent architecture is a practice that can help maintain this focus.

• ■   Delaying testing until later Sprints   All aspects of development, including testing, must be done during the Sprint. Delaying testing produces technical debt and undone work that accumulates exponentially.

• ■   Minimizing change (because change is bad)   Change is a fact of life in complex product development. Scrum embraces this fact through the use of shorter Sprints and an ordered Product Backlog maintained by an engaged Product Owner.

• ■   Assigning work (command and control)   The Developers are self-managing and can create and take ownership of their own work. They are also expected to estimate, forecast, and plan the work as a team, not relying on proxies.

• ■   Following the plan and conforming to the schedule   In Scrum, the plan is broken up into Sprints of one month or less in length. Beyond that, there is no firm plan, only a Product Backlog with items ordered in a way that represents what the Product Owner would like developed next.

• ■   Realizing no product value until the very end   Every Sprint must generate an Increment containing business value. This means that all development activities, including integration with other teams and systems, must be done at least by the end of the Sprint to realize this value.

• ■   Always reporting a bug   The Developers are self-managing and can determine whether or not the unexpected behavior is a bug. They are also capable of just correcting that behavior rather than creating a work item to report the bug. Remember: Failed tests are not bugs.

• ■   Treating Daily Scrums as status meetings   The Daily Scrum is for the Developers to synchronize and create a plan for the next 24 hours. It’s not meant for other purposes or for others to participate.

• ■   Never reestimating work   Professional Scrum Developers understand that they know more today than they did yesterday. Applying this new knowledge to existing estimates (either PBIs or tasks) is a healthy practice that increases transparency.

• ■   Sacrificing quality   The Definition of Done, when properly adhered to, protects the quality of the work the Developers do and keeps undone work, and any ensuing technical debt, out of the Increment.

• ■   Gold plating   The Developers only need to develop what is “fit for purpose” for a given PBI, and nothing more. In Scrum, the Developers shouldn’t try to predict what might eventually be needed. The next Sprint’s work will be revealed just in time.

ScrumButs

Many organizations have modified Scrum against this guidance. In their minds, they are doing the right thing and adapting Scrum to fit their particular flavor of chaos. This is partly because past approaches required tailoring in order to succeed. Scrum is the opposite in that changing Scrum itself can prevent you from succeeding. These changes and tweaks are colloquially known as “ScrumButs.” When a representative is asked if their organization or team is doing Scrum, they answer, “Yes, we are doing Scrum, but . . . .”

In fact, a ScrumBut has a particular syntax:

We use Scrum, but (ScrumBut) because (Reason) so (Workaround).

Here is an example of a ScrumBut:

“We use Scrum, but we don’t have Daily Scrums because they are too much overhead, so we only have them once a week or as needed.”

ScrumButs are excuses why teams and organizations can’t take full advantage of Scrum. ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side. For more information on ScrumButs, visit www.scrum.org/scrumbut.

Organizations may make short-term changes to Scrum in order to give them time to correct deficiencies. For example, a team’s Definition of Done may not initially include all the desired testing because of external dependencies or the length of time to develop an automated testing framework. For these Sprints, transparency is compromised. The Scrum Team should work to restore it as quickly as possible.

Note Several Professional Scrum Trainers feel that “ScrumBut” is too negative. Although they acknowledge that they exist, they prefer using a softer, more optimistic metaphor, such as an “adoption compromise” or simply “ScrumAnd.” While these are more diplomatic sounding, they still suggest that compromises are being made to the rules of Scrum during adoption. Hopefully a Professional Scrum Master is tracking them and they will be removed as soon as possible.

Becoming a Professional Scrum Team

No matter where you are in the game of Scrum, you can always improve. Whether you’re a part of a new team just getting started and still not sure what a timebox is, or your team has released many Increments of product successfully using Scrum, there are always new things to learn and new ways to enhance your practices.

A Scrum Team should inspect and adapt constantly. This includes the behaviors and practices of the team beyond simply identifying and removing dysfunctions. The absence of a dysfunction is an improvement, but the team can do even better. For example, it may take several Sprints for a dysfunctional Scrum Master to stop providing estimates on behalf of the Developers. Yes, I’ve actually seen this. It may take even more Sprints for the Developers to understand how to estimate on their own. It may take even more Sprints for these estimates to normalize. It may take additional Sprints for the team to learn that estimation is about conversation and learning, and not about the number.

Improvements can occur only if the culture allows it. The organization and management must allow their teams to experiment, fail, inspect, and adapt. Successful organizations yield successful teams because they allow their people the freedom to explore, learn, cross-pollinate, set up practice communities, and implement their retrospective items. Most of all, the culture must understand that improvement takes time.

In this section, I discuss ways in which a Scrum Team can continue to improve beyond just knowing and practicing mechanical Scrum. I call these teams Professional Scrum Teams.

Get a Coach

There may be times when the Scrum Team needs help improving their game. Just like any sports team, a Scrum Team can also benefit from the help of a coach. This kind of coach is an expert in Scrum, both in theory and in practice. They have an in-depth understanding of the practices and principles of Scrum, and they have real experience with Scrum. A coach like this can teach and coach all of the Scrum roles, including stakeholders and the organization itself, effectively. They can teach new patterns and behaviors for increased collaboration and high-performance achievement.

Note Don’t confuse a Scrum coach with an agile coach. For teams doing Scrum, they will want a Scrum coach who absolutely knows Scrum. This may take the form of a contracted Scrum Master. Agile coaches may or may not know Scrum, and they may even vary on what or how much they know about contemporary agile practices. These days you can’t swing a dead cat within an organization without hitting an agile coach. On the other hand, nobody accidentally becomes a Scrum coach.

A good Scrum coach will also have experience in a variety of organizational settings, which is useful when educating the rest of the organization. A coach can help the organization understand how the changes will affect leadership and team member responsibilities. Mentoring and gradually sharing proven practices about Scrum adoption ensures that the shock to the organization won’t be so painful.

Tip When searching for a Scrum coach, pay attention to the candidate’s background and if they have experience playing the various Scrum roles. It’s hard to find a coach who has played the role of the Product Owner, Scrum Master, and Developer. At least make sure the candidate has played the role you need the most help with.

There is a myth surrounding what a Scrum coach does. People think that coaching is purely a soft-touch approach—only providing guidance and the ability for people to discover problems and solutions for themselves à la the Socratic method. People also think that coaches do not tell people what to do. Some coaches fit this mold and, in my opinion, fall short of what is typically needed. The truth is, coaches need to have the difficult conversations, and these conversations are sometimes not nice and not polite. This is because coaches help people identify and overcome unpleasant things. One minute the coach will need to be compassionate and understanding and the next minute authoritative and uncompromising. People skills are necessary, but so is being assertive and resolute.

Build a Cross-Functional Team

The team of Developers is a cross-functional body of people possessing all the different skills required to turn PBIs into an Increment of Done, releasable functionality. The Developers need to know all the skills necessary to turn the PBIs into something that the organization defines as Done. Those Developers will need to acquire the skills of analysis, design, coding, testing, content development, deploying, operations, and so on.

It may take several Sprints for the Developers to even know what skills they have or are needed. When Scrum was first adopted in an organization, hopefully all of the analysts, coders, and testers were united onto teams. Since each of them played a role in the development of the product, they became known as a Developer. As self-managing and collective ownership attitudes emerged, the backgrounds and titles previously held by those team members became blurred and hopefully forgotten.

Note The opposite of a cross-functional team is a dysfunctional one.

What is a cross-functional team today may not be so tomorrow. Over time, the team, not the management, may determine that additional team members are required. To satisfy this need, new Developers may be added, or the current ones trained, in order to support new tools, technologies, or domains being considered. The opposite may also become a reality—fewer Developers may be needed because they have acquired more cross-functional skills and capabilities.

Tip In Scrum, the Product Owner provides the vision and Product Goal(s) for the product. This should be reflected by the PBIs, and their order, in the Product Backlog. An ordered Product Backlog serves as a roadmap for the planned features. It also serves as a roadmap for the planned technologies and new domains, which can serve as a “heads-up” for what functionality (skills) the Developers will need in the future.

Making unnecessary changes to the team of Developers will cause problems. When the problems that these changes cause are less than the problems caused by not changing, then it is worthwhile. You should be aware and prepared for the difficulty that a new team member will have when being introduced into an existing team. If you refer back to Bruce Tuckman’s stages of group development, any changes made to the makeup of a team will cause the team to revert to the forming stage of his model. Just think of the problems associated with a child when their family moves to a new town with a new school and the effort that has to occur for that child to fit in and be productive. Developers are not much different.

Note Don’t confuse cross-functional teams with cross-functional individuals. These are akin to T-shaped individuals. Scrum demands cross-functional teams of Developers. This means there must be at least one Developer who is capable of performing each type of task in the Sprint Backlog. For example, if there are Python tasks that must be accomplished, there must be at least one Developer who can code in Python. Professional Scrum Teams endeavor to have cross-functional individuals as well. This means that if Python tasks are becoming more prevalent in the upcoming Sprints, one or more Developers should acquire that knowledge. Having a cross-functional team of cross-functional Developers is a recipe for meeting goals and delivering an awesome product.

Achieve Self-Management

Scrum relies on self-managing teams to handle the complexity inherent in product development. A self-managing team will approach a challenge, and, based on the goals and requirements, decide how best to develop a solution while taking advantage of each team member’s various strengths. It takes a certain mindset and aptitude to be able to self-manage like this. But, compared with traditional practices—such as a chief architect creating the initial design or a project manager assigning work—self-management is a revolutionary improvement.

Every Developer on a self-managing team will work, independently, in pairs, or in a mob toward some shared goal. Everyone collaborates to reach the goal, valuing the team’s outcome over individual productivity. Members of the team trust each other and are interested in each other’s work, providing constructive feedback where appropriate. Self-managing teams are able to get work done and develop a valuable Increment. They are not blocked by impediments. They communicate any issues appropriately to achieve transparency.

An organization must allow its Developers to self-manage. This comes with time and the earning of trust. That trust is a direct result of the Developers being able to deliver increments of business value regularly in the form of working product. Education, provided by the Scrum Master, can help the organization see that this is a reason to trust the team. Once that trust is in place, hopefully the Developers will be given more leniency to make their own decisions and plans, and then be allowed to execute them.

Improve Transparency

Transparency, along with inspection and adaptation, are the three pillars of Scrum, or any empirical process control approach for that matter. The importance of being transparent—as a Developer to the rest of your team, or as a team of Developers to the Product Owner, or as the Scrum Team to the organization—cannot be overstated. Significant aspects of the development process must be made visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so that observers share a common understanding of what is being seen.

In Scrum, being transparent means that all observers should understand the basics of the framework, as well as the artifacts they may be looking at: the Product Backlog, Definition of Done, burndown charts, task boards, the Increment, and so on. The output and data reflected in these artifacts are like beacons of light. They shine brightly into all corners of the Scrum Team’s activity, leaving nowhere for slackers or other waste to hide.

Some Developers might be reluctant, or at least uncomfortable, about this “nowhere to hide” quality of Scrum. Nobody wants to work in a glass house, even though doing so means that a Developer will be more productive and exhibit healthier behaviors because they never know who might be watching. Being able to admit mistakes and ask for help will assist everyone in becoming more comfortable with this quality of Scrum. Besides, making mistakes and learning from them is a good way to improve.

Take the task board, for example. Whether we are talking about a physical one or an electronic one like in Azure Boards, it is a great information radiator and source of transparency. The board reflects the Developers’ current plan. It shows where they are, what they’ve done, and what they still have to do. The transparency of the board is not created for the sake of reporting, but rather for planning and general awareness. This awareness enables the team to manage themselves.

Professional Scrum Developer Training

Professional Scrum Teams who want to build and deliver great products require the understanding and integration of Professional Scrum, a well-functioning team, proven practices, and modern tools. Scrum.org’s Professional Scrum Developer (PSD) course is the only course available that teaches how this can be done.

The PSD course teaches students how to work in a team, using Professional Scrum, contemporary software development practices, and Azure DevOps to turn PBIs into Done, working product. All of this is done as iterative incremental development within the Scrum framework. The course was developed in partnership with Microsoft, Scrum.org, and Accentient. You can learn more about the origins of the Scrum Developer program, as well as Scrum.org, at www.scrum.org/about.

The PSD course is suitable for any Developer on a Scrum Team, including architects, programmers, designers, database developers, business analysts, testers, and others who will be contributing to the work. Product Owners, Scrum Masters, and other stakeholders are welcome to attend this class, as long as they keep in mind that all attendees will be expected to participate as a Scrum Developer—delivering Done, working product within mini-Sprint timeboxes.

As with all Scrum.org courses, the curriculum and materials are standardized and regularly enhanced by courseware stewards through contributions from the community of Professional Scrum Trainers and students. Only the most qualified instructors are selected to teach the PSD course. These are individuals with top-notch skills in the technologies coupled with excellent knowledge of how to use them within the Scrum framework. Each instructor brings their individual experiences and areas of expertise to bear, but all students learn from the same core content. This improves a student’s ability to pass the Professional Scrum Developer assessment and apply Professional Scrum in their workplace. For more information on the PSD program, training, and certification, visit www.scrum.org/psd.

Assess Your Knowledge

Scrum.org also provides tools that you can use to examine and enhance your knowledge of Scrum. The primary aim of these assessments is to provide information about an individual’s level of knowledge and thereby to enable improvement.

Each Scrum.org assessment is based on the Scrum Guide and developed by Scrum thought leaders with formal input from a wide range of industry experts and then enhanced with input from the larger Scrum community. The assessments are then monitored in an ongoing attempt to ensure their continued integrity and relevance.

• ■   Professional Scrum Master   Three levels of Professional Scrum Master assessments (fundamental, advanced, and distinguished) that validate and certify knowledge of Scrum and the ability to apply that knowledge.

• ■   Professional Scrum Product Owner   Three levels of Professional Scrum Product Owner assessments (fundamental, advanced, and distinguished) that validate and certify knowledge of Scrum Product Ownership and the ability to apply that knowledge.

• ■   Professional Scrum Developer   An assessment that is structured to validate and certify knowledge of the practices and techniques that support building complex products as a Developer on a Scrum Team and the ability to apply that knowledge.

• ■   Scaled Professional Scrum   Validates and certifies knowledge of how to scale Scrum and the use of the Nexus Framework and the ability to apply that knowledge. I discuss the Nexus Framework and Scaled Professional Scrum in Chapter 11.

• ■   Professional Scrum with Kanban   Validates and certifies knowledge of how Scrum Teams can use Scrum with Kanban to support value creation, measurement, and delivery. I discussed many of these topics in Chapter 9, “Improving Flow.”

• ■   Professional Agile Leadership   Validates and certifies knowledge of how agility adds value and why leadership’s understanding, sponsorship, and support of agile practices are essential.

• ■   Professional Scrum with User Experience   Validates a fundamental level of understanding about how to integrate modern UX practices into Scrum to deliver greater value.

Those who achieve a minimum passing assessment score receive certification. All Scrum.org assessments use the most recent version of the English Scrum Guide as the source for questions regarding the rules, artifacts, events, and roles of Scrum. Reading the Scrum Guide alone will not provide enough preparation for someone to pass an assessment. Questions often ask test-takers to interpret information and apply it to challenging situations, so knowledge gained from personal experience of Scrum, as well as other sources, is typically required. For more information on the various Scrum.org assessments, visit www.scrum.org/assessments.

Scrum.org also offers many tools and resources free to the community. Among these tools are several “open” assessments. These assessments have no fee and can be taken anonymously. There is also no certification associated with passing an open assessment. They do allow you to gauge your basic knowledge of Scrum, the Scrum roles, and related practices. The questions on the open assessments do not have the same level of difficulty as the certification assessments. They do, however, provide practice for the actual assessments. For more information on the Scrum.org open assessments, visit www.scrum.org/open-assessments.

Become a High-Performance Scrum Team

High-performance Professional Scrum Teams are the best of the best. They have mastered the key pillars of Scrum: self-management, transparency, inspection, and adaptation. They have focus, exhibit courage and openness, believe in and practice commitment, and respect others. They know the rules of Scrum according to the Scrum Guide, and they are able to deliver Increments of business value regularly in the form of working product.

It’s possible to become a high-performance Scrum Team through continuous improvement, as Figure 10-7 illustrates.

FIGURE 10-7 Teams can progress from not doing Scrum all the way to High-Performance Scrum.

Looking at a distribution curve and contemplating your own situation, you might be wondering, “Is my team doing Scrum?” It turns out that this is a harder question to answer than you might think. One might believe that just reading the Scrum Guide, filling all the roles, participating in all the events, and using the artifacts correctly would be enough. Even just the mechanics of doing Scrum is not easy to define.

Note In November 2011, several Professional Scrum Trainers met in Redmond, Washington, prior to Microsoft’s Application Lifecycle Management (ALM) Summit. One of the items on the agenda was to create a way to definitively determine whether a team was on the left side of the first dotted line in Figure 10-7. Teams wanted to know if they were “doing Scrum.” To determine this, we created a simple, measurable checklist that a team could answer. If all questions were answered in the affirmative, that team was doing Scrum. The determination of “how well” they are doing Scrum and where they are at on their improvement journey will need to be the subject of a future survey.

Here is an unofficial survey, representing the musings of several like-minded Professional Scrum Trainers, to determine if your team is “doing Scrum”:

1. Does your Scrum Team maintain an ordered Product Backlog?

2. Does your Scrum Team have a Product Owner, a Scrum Master, and three or more Developers, with an overall size of typically 10 or fewer people?

3. Does your Product Owner actively manage the Product Backlog?

4. Does your Scrum Master actively manage the process?

5. Do you have fixed-length Sprints of one month or less?

6. Do the Developers create a Sprint Backlog during Sprint Planning?

7. Can progress be assessed from the Sprint Backlog?

8. Do the Developers develop a Done Increment of product each Sprint?

9. Does your Scrum Team hold Sprint Reviews and Sprint Retrospectives?

10. Do your stakeholders inspect the Increment and provide feedback?

11. Does the Scrum Team inspect its process and make actionable improvements in follow-up Sprints?

All throughout this book, I have provided patterns to adopt and anti-patterns to avoid when it comes to practicing Professional Scrum—especially in the context of using a tool like Azure DevOps. All of this guidance, in addition to adopting and living the core principles and values of Scrum, will enable you and your fellow team members to become a high-performance Professional Scrum Team.

Chapter Retrospective

Here are the key concepts I covered in this chapter:

• ■   Professional Scrum Teams know Professional Scrum   Know the rules of Scrum and how to overcome its common challenges. These teams also know that dysfunctions should be identified and removed as they inspect and adapt.

• ■   High-performance Professional Scrum Teams continually improve   These teams are hungry to do better and take every opportunity to inspect and adapt, remove, or mitigate dysfunction, and continuously improve their game.

• ■   Remove impediments; don’t manage them   Remove your own impediments rather than relying on the Scrum Master to do it for you.

• ■   Estimate as a team   Help the Product Owner keep the Product Backlog refined, including estimating the size of upcoming PBIs. Estimates will organically improve over time.

• ■   Assess progress   Use burndown charts, work item counts, passing tests, flow metrics, or other practices to assess your team’s progress toward a goal.

• ■   Renegotiate scope when needed   This can happen, and when it does, collaborate with the Product Owner to accommodate the change. Constant changing of scope is a dysfunction.

• ■   Leave canceling a Sprint up to the Product Owner   Only the Product Owner can cancel a Sprint. It is a traumatic event and should be avoided if possible.

• ■   Ensure every PBI is Done before being released   Every PBI should be completed according to the Definition of Done. Undone work should not be released.

• ■   Avoid undone work   Unfinished PBIs cannot be released and shouldn’t be inspected during Sprint Review. Instead, they should be put back on the Product Backlog for refinement and consideration to be developed in a future Sprint.

• ■   Quarantine undone work with feature flags   Feature flags are a technique where functionality can be selectively excluded, disabled, or enabled from released software.

• ■   Use spikes to increase knowledge   Spikes are experiments performed by the Developers to learn and prove feasibility. Consider representing larger spikes in the Product Backlog.

• ■   Scrum supports fixed-price contracts   Scrum works as well as any other process when it comes to fixed-price contracts. It works better when a level of trust and sharing of risk exist between the Scrum Team and the customer.

• ■   Measure performance at a team level   Measuring performance should be done at a team level, not an individual level.

• ■   Inspect and adapt   Take advantage of the built-in Scrum events to ask yourself and your team how are you are doing with the product, as well as the process. Be sure to act on any of any findings that require it.

• ■   Don’t change Scrum   The framework is already barely sufficient, allowing any number of complementary practices to be implemented. Changing Scrum is usually done to hide underlying dysfunctions.

• ■   Scrum is like chess   You either play it as its rules state, or you don’t. Scrum and chess do not fail or succeed. They are either played by the rules or not.