Net Objectives’ Approach To Scrum

In FLEX

Exploring Team Agility With Scrum

Here are some useful resources for those who have adopted Scrum:
  • Introduction to Team Agility describes how to do Team-Agility but also provides insights on alternative practices you may find useful in Scrum.
  • Net Objectives' Approach to Scrum
  • Scrum as Example is a way to start simple by thinking of Scrum as the top drawer of a big toolbox, only going into the bigger toolbox when needed to solve problems.
  • Net Objectives' Scrum Support System provides templates, solutions to common challenges and more for those doing Scrum

Resources for Scrum

 

Training in Scrum

Provide Feedback

Net Objectives has been doing Scrum for almost two decades. We believe Scrum can be an excellent team framework in most situations. Scrum has been called “simple to undertand but difficult to master.” We believe that this difficulty can be greatly reduced by:

Our approach is about learning Scrum to support the teams’ contribution to business agiity – the quick realization of value predictably, sustainably and with high quality.

We have found that to have a quick, effective Scrum adoption requires the following:

Although Scrum is a framework that can work most anywhere some sort of development is being done, it is much easier and effective to adopt if, when Scrum is being adopted by a software development team, its roles, practices, artifacts and events are tailored for that context. This creates a focus on the actual which:

  • avoids having to reinvent the wheel
  • creats a focus on the actual work to be done
  • lessons resistance to Scrum because teams can see how it will make their life easier

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 entire organization’s.

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 osf 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 small, write 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.

Start simple, but prepare the teams for upcoming challenges

Teams need to be given a well-defined set of roles, artifacts, events and rules when starting something new. While it is often valuable to do some tailoring of Scrum to fit your context right from the beginning, it is also possible to start with Scrum exactly as it is defined and just think of it as an example of what can be done. We call this  Scrum as Example and it can to start with Scrum but have the attitude that it can be changed later as needed and as appropriate.

Enable Scrum to Work When You Don’t Have Cross-Functional Teams and/or Can’t 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. S

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.

Proper Training 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 (another name for Behavior Driven Development – BDD).

Why We Diverged From The Scrum Guide

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
  • Estimataion 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.