PART X: Using FLEX to Both Enhance and Simplify Scrum

ToC Why Agile Coaches Need to Know Both Scrum and Kanban

Note: This page was written before the acquisition of FLEX by the PMI. Now, we’d recommend learning Disciplined Agile Delivery which includes the useful concepts and practices of both Scrum and Kanban. However, this page is still useful for those who want to improve their Scrum adoptions.

Scrum is clearly the most popular Agile team framework. It is also the basis of most of the frameworks attempting to achieve scaled Agile (e.g., LeSS, Scrum@Scale, Nexus, SAFe). Scrum was designed to be a framework for an individual team creating a product. It is now mostly used by other types of teams doing other things. Although it may have made sense in the early days for Scrum to be based on empiricism and the belief that frameworks needed to be as simple as possible and requiring people to figure out what to do, new insights and evidence suggest it is time to go past these tenets. We now have a clear understanding as to why Agile works and we’ve learned many principles and natural laws that enable teams to be better prepared for getting their work done.

This page has the following sections:

Questioning the beliefs underlying Scrum
Improving Scrum
Alternatives to Scrum
Blogs to be incorporated into the above sections

Questioning some of the beliefs underlying Scrum

Reading this section is not necessary to get value from the sections below. But understanding the belief system underlying Scrum is worth the investment.

The Scrum guide states that “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.” While empirical process control theory is only an aspect of empiricism, we can accept this conflation because the intent is clear – we will take action based on the results we get.

Empiricism is not the same as the scientific approach, but only one aspect of it. The scientific approach is a combination of empiricism (for getting information and for either supporting or invalidating hypotheses) and rationalism to build a meta model with which to better understand reality. This meta model also enables us to make predictions about what will happen in certain situations.

Scrum’s focus on empiricism has had it eschew both a scientific exploration of its foundational practices (i.e., its “immutable roles, events, artifacts and rules” are not to be critically examined) and the creation of a model that might explain why Scrum’s practices are good. While this increases focus and makes Scrum simpler, it also has the risk of leaving practitioners in situations where they are provided little insight to solve their challenges. This dilemma often leads to Scrumbut since they can’t get Scrum to work but don’t understand a viable alternative.

I consider it ironic that Scrum, perhaps the epitome of Agile, has immutability baked into it. This is a necessary result of the lack of the an underlying model that would explain both why Scrum works and how people could decide on better alternatives to the immutable practices in their situation. The understanding on how to do this has been available for over a decade. Ironically, this understanding stems from Lean, which is now acknowledged as being where Scrum springs. A few of these are:

Delays in workflow and/or feedback cause extra work
Handoffs lose information and cause delays
Working on and completing small items of work helps the process
Work going beyond the capacity of the people doing the work causes delays and multi-tasking
Shorter learning cycles is better than longer ones
People doing the work are more familiar with it (and therefore what to do) than their management

It takes only a moment of reflection to see that Scrum’s self-organizing, cross-functional teams working in short sprints attend to these.

Not having a meta-model is what requires Scrum to have immutable practices. This given set will work – if you can do them. But they are not always best suited for a particular team. At that point they are not sure what to do. This makes it difficult for Scrum teams to find alternative approaches – they have not only not been trained to do so, they’ve been encouraged not to.

When the frustration of not being able to get a Scrum practice to work and without the proper understand of what to do instead, it should not be surprising that many teams just take an expedient approach that doesn’t work. Dropping the strict iterations and calling what they do Kanban, even though it isn’t is an example.

Many Scrum proponents argue that avoiding a meta-model is important because one will get trapped into believing a model when the model is wrong. I consider this to be no worse than getting trapped into a set of roles, events, artifacts and rules that may be less than optimal. But the reality is that, as George Box commented “All models are wrong, some are useful.” He did not mean we should not have models, but that we had to distrust them and to challenge them. We should not be defending our models – we know part of them is wrong.

Another part of the Scrum model is that it is intentionally simple and that people can figure out what they need. Keeping things simple to explain is good, but not having a sufficient set of practices needed is not. Frameworks can be architected so that practices can be presented as needed – making them simple to use.

The conjecture that adding items to a framework makes it more difficult is no more true than adding features to a system inherently makes it more complicated. This is only true if the system is poorly architected. Scrum’s simple architecture is what makes it harder to extend – not that it is not possible to do so.

The interested read may want to read these blogs that relate to this section:

Improving Scrum

Before we talk about improving Scrum, it’s important to understand what’s good about it. Scrum promotes:

Co-located, self-directed, cross-functional teams
All team members are equally responsible for the quality of the code.
Someone needs to have responsibility on what to build
A coach outside of developers is usually useful
Limit work in process
Track completed work
Avoid interruptions
Quick feedback
Quick pivots
regular retrospections
Cadence
Small stories
Regular demos

Regardless of your method, you should be working towards these. But those aspects of Scrum that are immutable are not necessary to achieve these. Think of Scrum as a collection of ways to get things done. There may be a better collection that fits your teams. Don’t worry about whether this better collection is Scrum or not.

The Difference Between Scrum and Lean. In 2004 I said that Scrum is a partial implementation of Lean. I said this not to belittle Scrum but to encourage people to learn more about Lean so they could improve their Scrum implementations.

Eight Steps to Improved Scrum. If you’re already doing Scrum and want to improve it, here are 8 things you can do to improve your Scrum.

Team Agility Support System. This is a fairly comprehensive support system for Agile teams using any approach. Those using Scrum will find How to improve or change your practices of particular value.

Eliminating Scrumbut

Eliminating Scrumbut with ScrumExcept

Blogs on Scrumbut

Alternatives to Scrum

Scrum is only one, of many, ways of achieving effective Agile teams. It has changed little over the last two decades. The essence of Scrum can be used as the basis for for effective teams. But re-thinking how to create Agile teams leads to an approach that can be better than Scrum. Here are a few of them.

The New Scrum Game. The original Scrum was inspired by The New New Product Development Game, a paper by Hirotaka Takeuchi and Ikujiro Nonaka who took the lessons of several companies using what product development methods that we now call Lean Product Development. While a massive step forward, Scrum was developed both without the knowledge we have now and with an overly restrictive focus on the team alone. This article describes what a Scrum developed with the context of what we now know should look like.

Scrum as Example has you start out with Scrum in the normal manner. But by considering Scrum as an example of how to do effective software development you can also modify Scrum as needed as you learn or face new challenges.

Disciplined Agile Delivery (DAD) and Lean-Agile at the Team: A Lean Approach to Scrum and Kanban.

The companies that created both DAD and Lean-Agile at the Team were acquired by the PMI in the fall of 2019. They are currently in the process of being integrated. DAD provides more practices while Lean-Agile at the Team provides more theory. The combination allows for a quick, well-defined start based on what the team adopting them needs.

Disciplined Agile Delivery is based on the idea that teams need to self-organize and choose their way of working (WOW).

Lean-Agile at the Team: A Lean Approach to Scrum and Kanban is consistent with Disciplined Agile Delviery which is more practices oriented than Lean-Agile at the Team. This is a good thing for those who want to select from a set of choices that will work for them.

Scrumban is not Scrum with Kanban. It is a team based approach based on Lean that starts with Scrum’s practices and moves people to Kanban. It is quite different from Scrum in philosophy and in implementation.

For Kanban and Kanban Method, see De-mystifying Kanban.