Background

There is no question that Scrum has changed the software world by leading the leading adopted framework in the Agile space. However, the Agile world has changed in the almost two decades since it was introduce. Here are some of the changes.

1. Late adopters are now moving into Agile.
2. Many of these are in large organizations.
3. Much more is known now about process, particularly in how to use Lean principles in software, than was known 20 years ago.
4. Some of Agile has moved from a focus on teams to include the entire organization.

The scope of current methods

There are several popular methods: Scrum, XP, Kanban, Kanban Method (LKU Kanban), SAFe, LeSS, and DAD.

The scope of these methods vary. Scrum and XP are centered around the team. Kanban directly encompasses the product backlog through deployment, but many Kanban thought leaders consider Kanban to include the entire value stream. The Kanban Method is mostly focused on after it has been decided what to work on. SAFe, LeSS and DAD include the entire value stream but take different approaches to it. While FLEX is not popular (yet) it also includes the entire value stream.

No one-size-fits-all and what that means

It is pretty much agreed that no one-size fits-all. But if we believe that, then we must ask the question – where do our methods fit? Those that are based on practices or scope will clearly have limitations on where they apply. Specific situations require specific practices. But there are several principles that apply most everywhere. There are even laws of software development that apply everywhere.

It therefore behooves us to see if our frameworks/methods are suggesting practices that don’t always apply or if they leave out useful principles / laws that do.

As Don Reinertsen pointed out, waterfall is not evil, it just doesn’t apply in the real world. We need to see where things work and where they don’t. The fact that things work differently and have different contexts in which they work is not bad. For example, I have two cars – a Mini-Cooper and a Lexus. They are different. The Mini-Cooper is great around town. It’s small, gets great gas mileage, is fun to drive and easy to park. But it’s not so good on highways (not a smooth ride above 60). My Lexus is way better for going 70 or more. Smooth, quiet, nice. But doesn’t get great gas mileage and is harder to find parking spaces for. One is not better than the other, they are only better than each other in different situations.

FLEX, while definitely not designed as a one-size fits-all, attends to providing pertinent practices for common situations & thinking on how to solve the rare ones. In this way it creates an umbrella for making specific recommendations for where people are.

Why Systems Thinking is so important

Systems Thinking is critical because it attends to how different aspects of our systems interrelate with each other. Transformations are fraught with examples of attending to one aspect of an organization only to adversely affect another. See If Russ Ackoff had given a TED Talk for why this is true. An example of not attending to the systems when doing pilots is discussed in this short video – Successful Pilots Can Hurt an Organization. In this example, successful pilots created effective Scrum teams but at the expense of making the rest of the organization. We must be careful we don’t solve the wrong problem.

Using Scrum to improve

Scrum provides specific practices to follow, including:

1. Cross-functional teams
2. Planned sprints of a consistent length
3. A product owner, Scrum Master and a team
4. Daily standups
5. A sprint backlog
6. A product backlog
7. Having work finished at the end of a sprint
8. Retrospections at the end of a sprint

It then lets the team figure out how to do it. Self-organization is the key here. When you can’t achieve these (most notably, cross-functional teams, not being interrupted during a sprint, planning for the sprint). Scrum goes further, however, and suggests that when you can’t achieve these practices that the way to improve your system is to remove these impediments. This provides a set of practices that people without a lot of understanding can follow.

However, there are a few problems with this. If no one-size fits-all then these practices will not always apply. While the intents are good, the practices are often either not generally applicable (the intention of sprints can be achieved in other ways) or the overly expensive to achieve (cross-functional teams is a way of avoiding handoffs, but not the only way when certain capabilities are scarce). There are several others which are currently being written up in our Team-Agility section.

The real danger to this approach, however, is that people new to scrum tend to think these practices are sacrosanct and, given Scrum provides no guidance on how to get past them, tend to become dogmatic. Another danger is that the focus on the team can have Scrum adoptions work more with intra-team issues when the real issues are inter-team or product management issues. See Successful Pilots Can Hurt an Organization.

The need for Double-Loop Learning

Systems-thinking tells us that we must attend to the system we are in when we make local decisions. This means we must often transcend any method we’re using. Double-Loop Learning is a way to challenge if what we are trying to do is, in fact, the right thing to be striving for.

Impediments to Scrum that may be reduced by looking outside of Scrum

One of the common impediments to Scrum is the lack of trust between business stakeholders and the team. It may be possible to lower the trust required if you can get alignment on what and why the business is investing in. Besides this positive benefit, it avoids the risk of teams evolving into silos.

Why it is important to include Scrum as an aspect of Systems Thinking

When a team undertakes improving their methods and select Scrum, it is important to understand the bigger goal – realizing value quickly – and the role they play in it. The roots of Scrum are in The New New Product Development Game which was about how to make a single team building a product more effective. By focusing on the team, Scrum may cause a focus on local-optimization. When a single team is involved, local optimization may be global optimization. But in our modern world, it typically isn’t.

In many cases having 2 or more teams working together will result in business value achieved both quicker and with more efficiency that a single team working by itself. Teams working together properly in a systems thinking approach may result in greater results than teams working by themselves.

Why it is so important to understand key principles before undertaking Scrum or adding them quickly

Most new teams learning Scrum make the same mistakes. These include:

• Opening up too many stories at the beginning of a sprint
• Not having enough agreement on how they should work together
• Not have good definitions of ready and/or definitions of done
• Not understanding effective ways to deal with interruptions

After a few sprints they’ve figured this out. However, basic Lean-principles could avoid them having to figure this out for themselves. In any event, practices such as explicit work-flow, managing Work-In-Process (WIP) and attending to root cause are core Lean practices that all Scrum teams should be using.

Better ways of revealing issues

One of the key intentions of Scrum is to frame the work to reveal issues. Following Scrum’s core practices are key to this. But there are other ways to reveal issues. The Value Steam Impedance (VSI) scorecard is one way of quantifying what people know intuitively about the impediments they face.