Day 1: Amplio Development: The Path to Effective Lean-Agile Teams

This article starts a daily update of my upcoming book: Amplio Development: The Path to Effective Lean-Agile Teams (web-page referred to points to a pdf of the book). I will be posting 2-6 pages worth a day on LinkedIn. Please ask questions and disagree respectfully in the comments here or on the LinkedIn Amplio Community of Practice User Group . We should finish going through the book sometime in the 3rd week of September. If you find this interesting and want to study with me for a year, check out the Amplio Development Master Class (paying for workshop) and the Amplio Community of Practice (free). Learn more about Amplio at a free seminar on September 8.

>> Day 2 Reading

Who This Workbook is For

This workbook is for people who want to learn how to work better. While it provides a lot of guidance on what to do, it is primarily a guide for learning. While providing practices, it focuses on objectives and why these are necessary. It also presents anti-patterns if you don’t use them. As you learn how to meet each objective, you also deepen your understanding of how things work.

This book is designed for consultants, trainers, coaches, mentors, and practitioners. While I had considered a book that explained the mechanics of Amplio and another one for coaches, I realized that all these roles are intertwined and some skill in all of them is necessary. Learning new concepts without being able to convey them is not very useful.

We view coaching as when it’s been decided what to do and the coach is helping people in accomplishing it.

Training is when new ideas are being conveyed.

Consulting is when someone is trying to help people decide what to do.

While most books focus on content alone or a specific role, we’ve found that you can’t split these out and expect people to be influential. To make understanding something meaningful, one must be able to convey the information to others. This is sometimes done as coaching or training or a blend of both.

How to read this book

This book is designed to be read in its entirety. Even if you’re not a coach, useful concepts are presented in the coaching section. It is recommended that you read Part I and Part II in parallel. However, quicker reading paths are possible:

If you are a practitioner or consultant:

Read from the front of the book to Part II: Being a Professional Coach. However, you will find reading that section useful when you need to convey concepts to others.

If you are a coach or mentor:

Read from the start to How Amplio Development Capabilities Are Organized.

Begin again Part II: Being a Professional Coach.

Then go back and read 5. Learning, Improving, and Pivoting

If you are a trainer:

Start with The Disciplined Way to talk to People. Then read from the beginning of the book.

Where to go for More

This book is used for Success Engineering’s Amplio Development Master Class .??

This workshop is intended for individuals who want to become premier consultants in Lean-Agile methods. It can also be used as the foundation for internal training. Besides the content of the book over a dozen virtual collaboration boards are used to teach it and given to participants to use in the work.

Please contact me at [email protected] to explore different ways to use this.

The Amplio Community of Practice is a free-to-join community that meets every other Thursday to learn about Amplio.

Part I: Understanding What You Need To Do

This section of the book focuses on the Amplio approach. In

1. Why we need a different approach from frameworks
2. The mindset of Amplio
3. The capabilities required to be effective
4. How to get started and continue learning

Why We Need a 21st Century Agile Team Approach

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contriving as constituting the only means for solving a given problem. – Buckminster Fuller

You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. – Buckminster Fuller

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 are not 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 countless teams and organizations having trouble with Agile. For most of the failed team-level initiatives, I’ve seen an attempt to use the Scrum framework. Some have had Scrum training; some mimic what they’ve seen. I believe that Scrum's design and mindset are flawed. Fortunately, people doing Scrum can take advantage of what they’ve learned by providing them a set of first principles that Scrum does not include.

Several salient points must be attended to:

1. People need a quick start that they can follow at the beginning.
2. There are no universal practices.
3. We can’t overload teams with too much information, but we need to make more information available after starting so people don’t need to reinvent practices.
4. It’s impossible to provide practices for everything but principles can be supplied to enable people to see what to do in new situations.
5. 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. Unfortunately, this is why it is “difficult to master.”

However, this approach ignores the following:

1. We now understand how and why Agile works and should take advantage of this
2. The principles of knowledge work, including software development.
3. What needs to be “simple” is not so much the design of the approach as the way it appears to the adopters of it
4. 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
5. 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:

1. “Scrum is intentionally incomplete.”
2. “Scrum is simple to understand but difficult to master.”
3. “Scrum is designed to expose impediments so the team can remove them. The responsibility for figuring out how to do this is with the team.”
4. “Scrum is like playing chess; you need to follow the rules at the beginning until you know more to transcend them.”
5. “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:

1. 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.
2. 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.
3. 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.
4. Use this method to create a fit-for-purpose way to start quickly.
5. 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.
6. 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.