How Amplio Development’s Capabilities Are Organized

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

Amplio Development is not designed just as a guide but as a learning method. Each of the capabilities is organized to provide both the action required, why it is required and different options to implement it. This is based on the concept that learning a practice and the principle on which it is based is the best way to learn how to improve. These principles affect many actions, so as they are learned for one practice it helps improve other practices. 

Purpose of this chapter

This chapter prepares the reader for how and why the practices suggested in the rest of the book are organized. There is a “chicken and egg” problem that needs resolving. Most people want a quick starting point. However, using a predetermined way for a team to do their work will likely not result in an approach that is fit for purpose. Amplio Development solves this dilemma by enabling participants to select a quick-start execution framework based on a few key issues. This starting point is to be considered the best the team knows how to work at the moment.

As the team works, it can improve its practices by considering other ways of working, evaluating them based on the value stream impedance scorecard, and trying them out and seeing if they work better.

Describing the Capabilities and the Practices

It is not enough to have an approach explain what to do, the approach must also provide for a way of learning what to do. Although you may be new to Agile methods, if you’ve been doing knowledge work for any length of time you have experience in the first principles – whether you were conscious of them or not. We will describe the capabilities you need to have by first looking to see what objectives must be met. It must also have a way for you to see what happens when you aren’t doing what’s needed. Therefore we include anti-patterns when the objectives aren’t being met.

By presenting the principles with a few practices that will meet the objectives, people can learn principles being used based on their past experience.

Organization of the Capabilities

28 capabilities have been identified as either being useful to most teams or often useful. Teams don’t need to start with all of them. Those capabilities that should be considered to be used at the start are identified as “core” capabilities.

Amplio Development’s objectives are organized as:

1. Managing the workflow
2. Requirements and Artifacts
3. Quality of products considerations
4. Organizing teams
5. Learning, improving, and pivoting
6. Roles

The book has a chapter for each of these sets of capabilities. Some of these capabilities are essential. Others are useful. The essential capabilities are labeled with **core**. The reader can read through all of the capabilities or just attend to the core capabilities and come back for the others later.

For Scrum Users

Amplio Development is not based on Scrum. As stated earlier, its foundation is the theories of Flow, Lean, the Theory of Constraints, organizational development, and personal behavior. However, since, people learn better when the information presented is given in contrast with what they know I will sometimes describe how Amplio Development is different from Scrum.

This section is for those using Scrum and discusses both what’s been added to it and what’s been removed. The additions are not always “Scrum And” because the addition of some of these concepts is not consistent with the Scrum model. The implication that you can add any good thing to Scrum is not true.

A different attitude than Scrum

Amplio doesn’t focus on being “intentionally incomplete.” It focuses on being “intelligently incomplete.”  It focuses on providing adopters the information they need, when they need it, without overloading them.

Amplio doesn’t find it acceptable that something is “simple to understand but difficult to master.”  Although building a product may be difficult to master, the approach taken should be simple to understand and relatively easy to master.

While you do need to learn the rules of the game, so to speak, you need to make sure you’re playing the right game. And you always want to understand why the rules of the game are there. This contrasts with many Scrum proponents saying “Scrum is like chess, follow the rules first, then you can change things.”

Amplio does not require any particular practice to be followed in order to be using it. The theory presented in Amplio allows you to improve on the practices provided without the danger of making your workflow worse.

What’s been added to Scrum

• A foundation of systems thinking, Flow, Lean, and the Theory of Constraints
• The value stream impedance scorecard can be used to determine if changing a practice will likely be an improvement or not. We often don’t need to run experiments to see if our actions will be improvements.
• Insights necessary for practitioners to extend the starting set of practices as needed.
• Objectives for each practice including why it’s important and -patterns when they are not met
• A recognition that there are no universal practices but that there are first principles
• Options for organizing teams when cross-functional teams are not applicable
• Be able to use a timeboxing or flow model, not merely be able to flow within timeboxing
• A focus on minimum incremental value delivery
• Some core technical practices when software is involved
• DevOps

What’s been removed from Scrum

• There are no immutable roles, events, artifacts or rules in Amplio Development. Anything that is consistent with first principles is ok. You select your practices based on what works according to your context and the laws of product development.
• Implicit distrust of management. While not technically part of the Scrum guide this distrust resides in the Scrum culture
• The idea that understanding only comes after doing. The two can be learned concurrently.

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

Go to Being a Professional Coach

.