Using Disciplined Agile Insights to Create a Quick Start for Effective Team Agility

Why we need a new Scrum

One of the attractions of Scrum is its simple definition and ability to start a team quickly. But this has proven to be a double edged sword. While one of Scrum’s creators, Ken Schwaber, implores “Scrum is simple, just use it as is” many teams find they can’t figure out how to use it. While many Scrum proponents claim this is due to management or the team itself not being motivated, it is just as often due to Scrum’s practices not being fit for purpose for the team. 

Teams struggling with Scrum abound so much that they’ve been given names – “dark Scrum” and “Scrummerfall.” The cause of this goes beyond the claims of Scrum proponents that “well, they just didn’t use Scrum.”

The reason for these challenges lie not so much on the people having difficulties with Scrum but Scrum’s focus on the how to do things instead of the what the intention is. Scrum’s basis of values, practices and empiricism provides no guidance for adjusting any of its predetermined practices. This leaves some teams with practices that don’t fit their needs well while not providing a way to find more suitable practices that would achieve the desired intent.

A Quick Introduction to Lean-Thinking

I like Michael Balle’s comment “The essence of Lean-thinking is to develop individuals so that they know how to do their job better and work better as a team.” Lean provides some theory which can be used to improve the delivery of value to the customer. It enables them to analyze what’s going on and suggesting certain things to achieve.

The need for theory is explained by this quote by Edwards Deming “Experience teaches nothing. In fact there is no experience to record without theory… Without theory there is no learning… And that is their downfall." People copy examples and then they wonder what is the trouble. They look at examples and without theory they learn nothing.” 

The essence of Lean’s theory is:

• Eliminating delays because delays cause waste (the essence of “just in time.”)
• Just-in-time. This means avoiding doing things early since the delay caused by doing so creates waste. This is typically implemented in a pull system which also decouples events from each other to avoid a cascade of timing errors from occurring.
• Use systems thinking. That is, looking at the whole and the relationships between the components in the system and recognizing that most of the behavior, and errors, that take place are the result of the system.
• Fix errors that are due more to the methods being used than to the people using them. Systems theory tells us that almost all of the errors are due to the system, so when an error occurs we must fix the system.

Lean also provides some guidance on how to achieve the goal:

• Work on small items
• Get quick feedback
• Attend to errors quickly because they provide insights into the way work is being done causes them and if they are not fixed, wasted effort will occur
• Make all work visible
• Make the agreements about how people are working together explicit

This combination of understanding the nature of work and having a few guiding principles enables the creation of a straightforward starting point that can also be used for continuous improvement.

A Team Approach Based on What How Why and WHO

A surprisingly short document can be specified that includes the what, how, why and who that is needed to help teams work better. The New New Product Development games, integrated with Lean lays out that we want to:

• Work on increments of value
• Validate them quickly
• Learn quickly
• Adjust quickly

Starting with these whats we can provide some hows. Providing Lean’s theory (the why) enables us to provide different hows along with a method for choosing what will work best for a given situation. Empiricism looks backwards in time telling us what worked or didn’t. Theory enables us to look forward to see what we expect to work.

The following tables describe what a Disciplined Agile approach to defining a team process would look like. It’s organized into three main sections: what (the intention we want to accomplish), how (a suggested practice or practices), and the why for both the whats and hows presented. This combination enables us to start with a way of working and then to modify it while ensuring we still accomplish what’s needed. The why column is based mostly on key Lean principles.

The table has two columns for the hows, one for a timeboxing or flow based approach. When deciding on the approach to take, a team must decide on whether to use a timeboxed or flow based system. Before continuing, let’s look at the differences between the two of them. 

Timeboxing means to have a set length of time for an increment to be built. Prior to starting work we see how much work can fit into the increment based on the time we have. Flow based systems, however, work on chunks of value to build. These are typically small and are grouped together to create an increment that can be consumed by the customer. Timeboxing automatically sets a cadence for when to start, demo the work and do retros. These times are when the timebox starts and the next one begins. Since the work going through flow systems can vary in length, flow systems require adding a cadence to them. This enables the cadence of starting, replenishing the backlog, demoing and doing retrospections to be decoupled from each other, which can be advantageous.

Timeboxing requires the ability to plan to the end of the timebox. This is applicable to new development but not so suited for maintenance work where items come in in an unpredictable manner. Timeboxing can provide discipline to new teams. These two factors are the main ones to consider when deciding between the two approaches. 

When looking at the tables that follow, consider which approach, timeboxing or flow, better suits your team.

A common misunderstanding

A common misunderstanding is thinking that queues are batches of work and that managing queues in a flow system means it is a sort of batch system as well. Or, that putting WIP limits on a batch system makes it a flow one. Queues should not be considered batches of work, but rather work waiting to be worked on. These delays cause additional work to be created and increases risk. Therefore queues should be managed whether you are using a batch or flow system.

The salient difference between timeboxing and flow is how work is taken in by the development team. In a batch system, the size of work is determined and work of that size is given or pulled by the team. In a timeboxed system, the size of the work is determined by the amount of work that can be done in a certain time. In a flow system, small pieces of work are pulled. While one may have a vision of a release in which to create a context for working on these items, there is an effort to pull small items, get them done, learn, and pivot is necessary before pulling the next item.

It is important to remember that putting a flow practice into a batch system does not make it a flow system.

How to use the tables if you’re already doing Scrum

If you are currently using Scrum, there is no reason to abandon what you’ve learned when using the following tables. These tables will inject the what and why into the how and who Scrum provides. With these you can often see better ways to achieve the intentions of Scrum than what Scrum provides. These may be additions or substitutions. If you substitute a practice you will not be doing Scrum anymore. But that should not be a concern. You are just now being guided by validated theory providing you insights into what you are trying to accomplish.

The numbers in the what column refer to the factors for effective value streams we've found to be useful. They are summarized in the following table.

Note that this is a work in process. This is the first part of an article that will be expanded to present a guide to team agility that is about 15-20 pages long, but designed without boundaries, options to choose from and the thought process to make good choices.

If you want to learn more about having an Agile team approach that works for you I suggest looking at Disciplined Agile's Scrum Master (DASM) Certification. Or, if you are already familiar with Scrum and want to learn how Scrum teams can work together, check out the Disciplined Agile's Senior Scrum Master (DASSM) Certification.

* In ’07 Al Shalloway, on the Yahoo Scrum Development group, suggested that Scrum was a partial manifestation of Lean. Ken Schwaber vehemently disagreed, expelled Mr. Shalloway from the group and asked for Jeff Sutherland (the other co-founder of Scrum) to support him, which Jeff did, while admitting that knowing Lean would benefit doing Scrum. Scrum does incorporate some Lean practices into it now. But incorporating a few Lean practices into a non-Lean mindset does not make it Lean. This is the same way putting daily Scrums into a waterfall process wouldn't make it Scrum.