Net Objectives has been doing Scrum for almost two decades. We believe 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.
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:
In addition, this:
Each of these, and other, advantages, are covered in topics below.
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.
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.
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.
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.
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.
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.
The Scrum guide tells us that its roles, events, artifacts and rules are immutable. This is fine if you want to ensure you are doing Scrum. Scrum is based on the philosophy that following its roles, events, artifacts and rules will facilitate Agile. While this is often true, doing so sometimes either cannot be done economically or at all. Cross-functional teams and being able to plan ahead is not something that can always be accomplished. Just as important, sometimes Scrum’s roles, events, artifacts or rules are not appropriate for a particular situation.
Just changing one of these arbitrarily, however, is not advised. There is a reason (objective) for the roles, events, artifacts and rules. While it may be advisable to change one, the new practice must achieve the original intended objective.
Making a change can be accomplished with this four step process:
There is no definitive set of alternative practices to Scrum. That is the entire point. But it is worth investigating a few of them to illustrate how Scrum as Example can be used.
How to tell if a change is better
There is a set of underlying principles that can provide an indication if a change will improve things. This is always in theory to some extent, because even if a change will improve things if made, there are often side effects caused by people not adopting the change that work against it. We therefore must always be diligent and validate any change we make.
The measure to use is the value stream impedance scorecard. In a nutshell, the VSIS indicates how much resistance the system will impose on work being attempted. It is based on what improves total value manifested. Lowering this resistance usually results in more value manifested.
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.
The challenges in adopting Scrum include:
These challenges are relatively straightforward to improve, but only when one attends to the context in which Scrum is being used.
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.
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.
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).
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:
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.