I have been teaching and coaching Scrum for almost 20 years. As I use it more and more I have found more and more I disagree with some of its fundamental tenets. We (Net Objectives) continue to use Scrum because I believe it is a good base from which people can learn more effective methods and because many people in the industry are aware of it. Furthermore, many who have tried Scrum and are struggling with it, or more accurately, are doing Scrum-but (“we do Scrum, but we don’t do …”) can be helped with the work we do. The Net Objectives Scrum / Team Agility Support System highlights how we think about and support Scrum.

Some of the concepts I disagree with are more thought processes or beliefs about how humans work and therefore may be hard to argue for. You will just have to see what matches your own belief system. Other concepts are more about what’s important for people adopting something new. In all of these cases I try to follow what works, based on my own and others’ experience.

This article will cover:

• What I like about Scrum
• What has changed for me over the last 20 years
• What I disagree with in Scrum
• The bottom line

What I like about Scrum

Scrum’s focus on self-organizing teams. Development is not just a technical process. It is a human process. Great creativity comes from great teams. One of the reasons I left Lean-Kanban-University was a fundamental disagreement I had with my co-founder David Anderson who felt teams were an orthogonal issue to Kanban. I believe teams are a fundamental aspect of development and cannot be ignored.

Time-boxing as a way of creating discipline and focus.  Although time-boxing is not essential (flow can guide teams instead) time-boxing is much easier to do for people new to agile. It acts as a forcing function – that is, encourages, focus on what’s happening next as well as requires small stories – both good things.

The defined responsibilities of the product owner stating what to work on with the teams providing the estimates of how long it will take.  This puts authority with responsibility and avoids teams having to be martyrs or victims.

Daily scrums and periodic retrospectives.  Developers are passionate and want to get stuff done. Without a forced daily scrum and scheduled retrospectives, it’d be hard to get them to do these (often still is).

Provides a simple base on which to build off of. The simplicity of Scrum allows for it to be used as a well defined starting point which people need.

What’s changed for me over the years

There have been three main trends over the last twenty years that have had me change my views from being passionate about Scrum to believing it needs to be modified to some extent.

Scrum is used inappropriately. Scrum is being used in organizations where teams are not independent and true cross-functional teams cannot be created.

Scrum was designed by innovators for innovators and early adopters. It is now being used by the mid to late majority. The assumptions of people figuring out things on their own are no longer accurate.

Much has been learned since Scrum’s creation. In terms of process, this includes Lean Thinking as applied to software development, Scrumban and the Kanban Method. In terms of the technical aspects of software development there are design patterns, emergent design, TDD, ATDD, BDD, DevOps, CICD and more.

How Scrum can be made better

Scrum’s roles, events, artifacts, and rules are immutable. This defines Scrum and the adoption of Scrum. It creates an extremely well-defined starting point which is a very good thing. It also creates a method of making decisions of whether a change is good or not. Double-loop learning needs to be incorporated into Scrum; this allows for challenging its assumptions. The Scrum Guide states “Scrum’s roles, events, artifacts, & rules are immutable.” If you change this to “Scrum’s roles, events, artifacts, & rules are immutable except when what they are changed to manifests the intent of what is being changed”

Scrum is based on a black box.  While this is not in the Scrum guide, it is in Ken’s first book on Scrum and everything I have heard him say since then is consistent with this belief. For example, Scrum’s immutability is not arbitrary. It results from a belief that the process to manage complex, non-deterministic systems cannot be well-defined. Scrum provides a simple, well-defined framework within which a loosely defined process is used. While software development is a complex, non-deterministic system, our actual workflow can be well defined as it is in Kanban.  I believe systems thinking incorporating Lean Thinking in particular can be used to explain the behaviors of systems, even if when not providing predictability. People don’t necessarily resist change when it can be shown to be in their best interest.

Scrum as a forcing function.  The above two beliefs set up Scrum as a forcing framework. That is, following the mandates of Scrum will push people into good practices (e.g., sprints require small stories – a good thing).  While this can work, is assumes that Scrum’s immutable roles, events, artifacts, and rules are the best fit. As we learn more and feel confident to change things it means we have to “abandon” Scrum. After being certified as a “master” going into uncharted territory can feel uncomfortable. It is better to have people understand the work they need to do and have Scrum be a supporting framework.

Achieving cross-functional teams. Scrum is inspired by “The New New Product Development Game” which was an approach for a development team to build a product. By definition Scrum was designed for a cross-functional team. When one isn’t present you are supposed to create one. But true cross-functionality in today’s specialized world is a pipe-dream. The attempt to get cross-functional teams is a good one, but how far do you go and what do you do when you’ve hit the limits. If one doesn’t recognize an underlying model of Lean flow you have little guidance except for “Scrum is simple, just use it as is.” What a “team” is may need to be redefined. People outside the development team may be part of the team if we can get them focused on working with the development team.

Initial training should be for the team.  The most prevalent initial Scrum training is Scrum Master training. While CSM training which focuses on the role of the Scrum Master is a good thing, teach a CSM, or any Scrum Master course, to a team is a non-sequitur to me.  People have limited time and budget and new Scrum teams should be taught as a team – product owner, scrum master and development team all together. Details needed for the product owner and scrum master can be deferred for them after the initial team training.

Scrum’s past attitude about management. While I agree with the daily Scrum being limited to those doing the work, at one time the “chicken and pigs” story talked about chickens being those not committed to the work. This is quite different from those not doing the work. My experience is that managers are often just as committed to the work and have an important role. However, the Scrum community does not state a well-defined role for managers (LeSS, in fact, still dismisses them). I find this ironic since Takeuchi Nonaka (one of the co-authors of The New New Product Development Game on which Scrum is based) wrote an article just two years later about the critical role management plays. See Toward Middle-Up-Down Management.

People will figure out what they need to add to Scrum. Scrum is a simple framework that people are supposed to add to. The implicit assumption is that they will. My experience is that they don’t. I base this on my observation of the common set of challenges that teams that are new to Scrum have:

• Too many stories get opened early
• Stories are too big (> 3 days)
• Acceptance criteria is not well known
• No Definition of Ready or Definition of Done
• Running mini-waterfalls in Scrum
• Product owners are not available as often as they should be
• Ineffective retrospections

A combination of Lean-Flow principles and using Scrum as a supporting framework can avoid most of these very early. By supporting framework I mean that people look to Scrum to help them support actions they know they need to accomplish. This is the opposite of looking to Scrum to guide them. Scrum has been very slow in adopting Lean which makes it difficult for Scrum  to be used as a supporting framework.

Needed clarification on self-organization.  The focus on self-organization of teams ignores that teams are working within a bigger context. This self-organization must be within that context of creating value and how to interact with other teams. For example, when deciding how long sprints should be, a team should consider the sprint length of other teams they interact with.

How to achieve the Scrum values. There is no question that the Scrum values of commitment, courage, focus, openness and respect are needed. The question is, what causes them not to be present and what can we do about it? This is one place that I have found systems-thinking to be essential. Systems thinking tells us that the system people are in has a huge impact on the people. Scrum does recognize this to some extent by trying to change this system by creating cross-functional teams. But it has further implication. It may be that people would have the Scrum values if they were in a better system, but don’t exhibit them where they are. Scrum seems to take the attitude that these values drive improvements. Systems thinking takes a different tact. It suggests changing the system will enable these intrinsic qualities to come out. The question is not if these are good values, the question is how does one illicit them if they are not present?

The bottom line for learning Scrum

Here is my bottom line for learning Scrum.

Initially just teach the basics of Scrum integrated with basic Acceptance Test-Driven Development. As the Scrum guide says, “Scrum is lightweight, simple to understand, and difficult to master.” Because of this, it is best to have initial training just provide an overview of Scrum and use the time saved to teach some basic ATDD in order to teach the team how to write small, well-defined stories. This training should also be done as a team, with all roles of Scrum (product owner, development team, and Scrum Master present). Separate Scrum Master and Product Owner training should be done for those roles. It is also important to teach Scrum within the context of Agile Product Management. This has teams learn Scrum within the bigger picture of value realization and not optimizing just their team.

Provide a support system.  What’s difficult to master is not Scrum itself, but using it to do Agile development. This has more to do with how development teams do Agile analysis, design, code and test. Simply training them in Scrum and turning them loose often leads to challenges. It is very important to offer a support system to those new to Scrum.

Here is what should be in the support system.

• Templates to provide checklists for teams and Scrum Masters
• A list of common challenges and their remedies faced by teams new to Scrum
• Case studies of how Lean Thinking can help people doing Scrum
• Scrum as Example – a way to think of Scrum as an example of what to do.

Scrum can be taught more effectively to software development teams when it is taught for software development.  Although Scrum can be used anywhere, most of the people using it are using it to develop software. Scrum can be taught more effectively to software development teams when it is taught for software development.