Contents

The essence of how our approach is different from Scrum Guide Scrum Specialize Scrum to software development Use Lean Thinking as a foundation: Do Scrum within the bigger picture of the organization Learn how to write small, well-scoped, testable stories Provide insights into how multiple teams can work together Use Lean metrics to aid in making decisions on what potential improvements to make Enable Scrum to work when you don’t have cross-functional teams and/or cannot do iterations Include patterns of solution for common challenges organizations have with adopting Scrum Getting teams trained in Scrum Provide Team Training to the Team How Scrum Masters should be trained Why Scrum Team training should include the Product Owners How a minor change to the Scrum Guide makes Scrum much more effective Resources on Scrum

Scrum can be an excellent team framework in many situations. Scrum has been called “simple to understand but difficult to master.” If you are using Scrum to develop software, this difficulty can be greatly reduced by using Lean Thinking as a foundation for Scrum and explicitly incorporating  what’s been learned about software development and incorporating it into Scrum.

Scrum can support teams in their role of contributing to business agility, the quick realization of value predictably, sustainably and with high quality.

The essence of how our approach is different from standard Scrum

1. Explicitly use Lean Thinking as a foundation for Scrum
   • Adopt a systems-thinking approach
   • Explicitly integrate a focus on time and quality into everything you do
2. Initial training should focus  more on peoples’ jobs and just enough of the framework they are adopting to get going
   • if delivering to software developers, specialize the training for them
   • focus on the intent of the framework
3. Provide a support system for after the training to help people with challenges that will likely come up for them

Specialize Scrum to software development

Scrum can be used for doing any kind of product development. While this is great for those promoting it, if your teams are going to be using Scrum for software development it makes sense to take advantage of what’s been learned over the last 20 years in the Agile Software Development community. There are several reasons for this. Some include:

• being able to anticipate challenges you will likely otherwise have and readily avoid them
• taking advantage of the patterns of Scrum adoption of the past 2 decadesdon’t have to re-invent the wheel on what pracitces you should use in Scrum
• learning Scrum in a much more effective way (see below) than learning Scrum first and then filling it in

In addition, this:

• avoids having to reinvent the wheel
• creats a focus on the actual work to be done
• lessens resistance to Scrum because teams can see how it will make their life easier
• enables the creation of a support system for the team to use

Each of these, and other, advantages, are covered in topics below.

Use Lean Thinking as a foundation

While Scrum does not directly come from Lean, it was inspired by the article The New New Product Development Game which was based on a study of what we would now call Lean companies. Explicitly taking advantage of Lean Thinking provides guidance to both inexperienced and experienced Scrum Teams.

Software is very different from the physical world. Perhaps the biggest differences are in that it is difficult to see how much work is in process and what the workflow looks like. The impacts of delay in software are also quite different than in the physical world. Learning Scrum with the difference between software and the physical world in mind is very important. Lean’s focus on removing delays in workflow, feedback and using information can be very useful here.

Do Scrum within the bigger picture of the organization

As Don Reinertsen says, “There is more value created with overall alignment than with local excellence.” What this means is that we should always be looking at the true goal – value realization to our customers. In today’s world, few teams truly work in isolation. Scrum must fit into the bigger picture from the very start. This does not mean we cannot start with Scrum teams but that they must know that we’re not trying to optimize their work as much as the work of the entire organization.

The most effective way to do this is to start with Agile Product Management so that teams can be provided thin slices of functionality that they can build and deliver. It is also important to include marketing, ops, business intelligence, and many other parts of the organization come into play. Agile Product Management provides the context within which Scrum teams should be working. Much of the benefits of DevOps can be achieved by merely including visibility on these interactions.

What is required for product management in an Agile context? It requires a relentless focus on value realization, seeking the highest business value in a shorter amount of time, predictably, sustainably, and with high quality while retaining the ability to pivot at low cost. It involves aligning the organization around this goal. It employs Lean thinking and Agile practices to realize these goals.

Agile Product Management is the key. Yet many organizations are still operating with a mixed collection of Agile and outdated traditional techniques.

Agile Product Management concerns itself with defining the value to be manifested by the business that aligns with its strategic goals. Here is what is involved.

1. Identifying, sizing and sequencing the work to be done in order to facilitate alignment across the enterprise. This includes the use of Minimum Viable Products (MVPs) and their counterpart in established organizations.
2. Understanding the relationship between business offerings and business capabilities and how this can be used to improve the methods of the organization and how not attending to it causes misalignment of efforts.
3. Creating an effective ecosystem for the above including the roles required.
4. Using Acceptance Test-Driven Development (ATDD) integrated with Behavioral Driven Developments Given When Then construct to create clarity on requirements.

Learn how to write small, well-scoped, testable stories

The most common challenges teams new to Agile have is how to write small stories. The typical starting pointsn of “As a <user> I want <function> so that <I get this value>” is a great starting point. But it can only be used so far. We have found that integrating Acceptance Test-Driven Development to the extent small stories are written is both necessary and sufficient to enable Scrum teams to get going. One does not need to start with automated testing, but small, clear stories, from day one is essential.

Provide insights into how multiple teams can work together

When only 3-5 teams are working together, large frameworks within which teams need to work are not necessary. It is effective enough to use shared backlogs or other techniques based on Lean flow.

Use Lean metrics to aid in making decisions on what potential improvements would be better

With the understanding of a few Lean principles (primarily remove delays in feedback, workflow and realization of value, avoid working beyond capacity, and attend to quality) one can be reasonably accurate in making good decisions on what would be an improvement to a practice. We have created the Value Stream Impedance Scorecard to provide a qualitative scorecard to help with such decisions.

Enable Scrum to work when you don’t have cross-functional teams and/or cannot do iterations

Many teams adopting Scrum either can’t get, or  it’s not not possible or advisable to create cross functional teams. In this case it may be advisable to do a more Kanban style team approach – which we also do. But Scrum can still can still be mostly used by relatively minor adjustments.

There are also times it’s not possible to have well-set iterations. In these cases, it is still important to have teams work in a cadence with others by adopting a flow approach without iterations. Sprints are not always advisable – particularly for maintenance or shared services team.

Include patterns of solution for common challenges organizations have with adopting Scrum

The challenges in adopting Scrum include:

1. Difficulty getting to small (<= three days to complete) stories
2. Too many backlog items get opened too early
3. Teams get frequently interrupted but management doesn’t understand the toll on the team
4. The burn-down/up graphs look like hockey sticks (i.e., not much gets completed in the sprint until the very end)
5. Developers discover they didn’t understand the requirement initially posed to them
6. Estimation taking a long time
7. Scrum teams tend to focus on optimizing their team instead of working towards the bigger picture of value realization

These challenges are relatively straightforward to improve, but only when one attends to the context in which Scrum is being used.

Getting teams trained in Scrum

Provide team training to the team

Many teams start out receiving Scrum Master training. But what it takes to be a Scrum Master and an effetive developer is quite different. We teach teams as teams – with all roles present, but with the focus on what the development teams. Product Owners need specialized training for what they need to do in helping prepare the product backlog. Scrum Masters need ongoing training that enables them to learn as they go. Their role is also not just about coaching the team in Scrum but how the team fits into the bigger picture of their organization.

How Scrum Masters should be trained

Scrum Masters need to attend the team training. While only about half of the training may be relevant to them, this provides an opportunity for greater collaboration between the Scrum Master and team. But, more importantly, it provides the opportunity for the Scrum Master to see what concepts the team is having troubles learning. It also lets the Scrum Master see how the team is taking to Scrum. These insights will be critical to the Scrum Master once the team actually starts doing Scrum.

This is just the beginning of Scrum Master training, however. It is presumed that a Scrum Master already has the attitude of being a good coach. This is not something one learns in days or even months. So pick your Scrum Masters carefully. Learning how to be a Scrum Master requires understanding what’s behind the challenges their team(s) is having with Scrum. This takes a considerable amount of experience.

The best way to teach this is with a several month long program that coaches the Scrum Master in their own work environment. They should be provided some deep Scrum learning each week along with some one-on-one coaching with an experienced Scrum Master. In this way they’ll learn by doing.

Why Scrum team training should include the Product Owners

We also believe Product Owners should be in team Scrum training as well. This helps teach these two roles how to work better together. Much of the work done in the Scrum involves developers and product owners working together. Product Owners define the “what” with the team deciding on the “how.” Since teams also validate what’s built the product owner and development team represent the customer, development and testing:  the Triad of Acceptance Test-Driven Development (which is another name for Behavior-Driven Development).

How a minor change to the Scrum Guide makes Scrum much more effective

The Scrum guide states:

“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.”

We believe in pragmatism over dogmatism. If Scrum is going to be adopted across an organization there sometimes requires changes to some of the aspects of Scrum that, by the guide, are immutable. A small change can be made that keeps the power of Scrum while eliminating the drawbacks of dogma. This is to change the above statement to:

“Scrum’s roles, events, artifacts, and rules can only be changed when what it is changed to manifests the intent of the role, event, artifact or rule being changed.”

In other words, don’t make changes lightly. But if you are having a challenge with a practice don’t assume that that’s the best practice for you. We do not lightly change standards. However, we’ve found that there are many common challenges with Scrum adoption that can be directly addressed and even avoided with taking the approach described above. We believe in pragmatism over dogmatism. We see the following challenges in Scrum Adoption to be common:

• the development team resisting Scrum
• Scrum training not being well retained by the development team and going back to old habits
• Product owners and teams are unable to create clearr requirements and to decompose them into small stories
• Estimation is both very inaccurate and takes a long time to do
• Teams use Scrum where the use of cross-funcitonal teams or sprints is not applicable
• Teams use non-Agile practices within a sprint
• Product Owners are not sufficiently involved
• Teams have challenges working together
• Management and/or leadership do not understand their role in Scrum.

Our approach to Scrum has been informed by seeing what actually works in practice. We believe in focusing on the work to be done. Consistency is, of course, necessary. But it should be consistency of intents and results. This is readily achieved by creating visibility of the agreements teams make with each other. See detail in how to do this with Scrum as Example.

Resources on Scrum

Blogs or Equivalent