Why We Need a 21st Century Agile Team Approach

This is a chapter from Amplio Development: The Path to Effective Lean-Agile Teams

Agile as a community working to find better software development methods started in the mid to late 90s. Innovators and early adopters were the first people to use it. Most teams were developing software products and were mostly autonomous and cross-functional.

Scrum is Agile’s most popular framework. It continues to be a framework geared towards identifying your impediments and having teams figure out how to solve them. But times have changed. Agile, and therefore Scrum, is used almost everywhere now, most of the time not where it was designed for. Most of the teams using it now are no longer cross-functional, autonomous, or working on creating a new product that Scrum was initially designed for.

Our problems have gotten more complex. Fortunately, we’ve learned a lot in the 27 years since Scrum was created. Unfortunately, Scrum has not picked up on much of this. The reason for talking about Scrum here is that it’s become the de facto standard for teams. Many teams have been trained in it or are modeling their work after it (sometimes incorrectly).

The book will help teams regardless of the approach they are taking. Its foundation in the theories of Flow, Lean, and the Theory of Constraints means it can be applied to assist any approach you are taking.

This is not another framework. Instead, it is an approach based on the science of product development and knowledge work. The concepts put forth here are not just my own. They have been corroborated by dozens of other senior consultants and thought leaders in many fields. This is not meant to be a personal journey but rather a discourse on what is effective. It is based on evidence, but, as George Box said – “all models are wrong, some are useful.” Pushback, when you disagree with this, is welcome. Questions, comments, and challenges to assertions put forth are welcomed. A LinkedIn group, The Amplio Community of Practice, has been set up to enter/ask these questions.

The incentive for this book arose from seeing the countless teams and organizations having trouble with Agile. Most of the failed team-level initiatives I’ve seen are attempting to use the Scrum framework. Some have had Scrum training; some are just mimicking what they’ve seen. I am not here to lay blame on anyone or anything. However, I do believe that the design and mindset of Scrum are flawed. I am not arguing for its abandonment by people using it, but I will point out an alternative approach that can be used on its own and used to improve Scrum initiatives.

Six salient points must be attended to:

• People need a quick start that they can follow at the beginning
• We can’t overload teams with too much information
• There are no universal practices
• We must make our framework as lightweight as possible so that it is applicable In more areas
• It’s not possible to provide practices for everything
• Our approach must not have boundaries on what can be done except that all actions must have a positive impact

Scrum took the approach to have a simple, intentionally incomplete framework where people would figure out what’s needed.

However, this approach ignores the following:

• We now have an understanding of the principles of knowledge work, including software development
• What needs to be “simple” is not so much the design of the approach as the way it appears to the adopters of it
• The way to avoid overloading people does not need to be by limiting how much is in the approach being taken but by in the way the approach is taught and the rate at which information is conveyed
• This enables the approach to convey a great deal of information and not be limited to just a core set of concepts

The weakness of Scrum’s approach is illustrated in comments that we often hear used to defend it:

• Scrum is intentionally incomplete
• Scrum is simple to understand but difficult to master
• Scrum is designed to expose impediments so that the team can remove them. The responsibility for figuring out how to do this is with the team.
• Scrum is like playing chess; you need to follow the rules at the beginning until you know more to transcend them.
• well, then they’re not doing Scrum – when a team goes off script and fails.

These comments, ironically, can be used to point us in the direction of what’s needed:

• We must provide information over time, as it is needed, to avoid overloading people. The focus is on the rate of providing information, not on how little to provide.
• The approach must be practical – easy to use and understand. Providing a set of principles that explains what makes knowledge work effective can accomplish this.
• Provide a way to look at the most salient aspects of these principles so people can tell if a suggested work change will be an improvement. This enables guided continuous improvement.
• Use this method to create a fit-for-purpose way to start quickly.
• Design the system to be able to include what works. Only exclude practices that violate the principles of knowledge work. No practices are off-limits if they are helpful.
• Include practices `that have proven to be useful for most teams.

The benefit of this approach is that teams and their associated management will understand what is needed. It enables them to work together better and assist each other. It also accommodates the shifts in who and where Agile is being used.

Go to Amplio Development: The Path to Effective Lean-Agile Teams

Go to Being a Professional Coach