How Amplio Development Is Organized

Amplio Development is not designed as just 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. 

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. 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.

Most approaches teach you what to do and assume the principles will be learned by doing.  Most people have been doing something for a long time, however. By presenting the principles with the practices people can understand the principles based on their past experience and use that to improve their future practices.

Amplio Developments’ objectives are organized as:

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

For Scrum Users

Amplio Development is not based on Scrum. As stated earlier, its foundation are the theories of Flow, Lean, Theory of Constraints, organizational development, and personal behavior. However, since, people learn better when they are presented information 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 are not consistent with the Scrum model. The implication that you can add any good thing to Scrum is not true.

What’s been added to Scrum

• A foundation of systems thinking, Flow, Lean, and Theory of Constraints
• A way of determining if a change to 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 anti-patterns when they are not met
• A recognition that there are no universal practices but that there are universal 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 universal 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.

Amplio Development’s Capabilities (Objectives)

Note: How to read this section.

This section is written as both an overview of what needs to happen and a reference guide. It is suggested that one first reads the opening paragraphs of each section – e.g., Requirements and Artifacts, Quality of the Product, …. Then one can go back and read each objective. Include reading the details of the objective if desired at this time or wait until you come back and read it as a reference.

Each capability is presented as follows:

• Objective
• Why it’s important
• Options on how to accomplish it
• Anti-patterns if you don’t

While each of the capabilities is presented in its entirety, feel free to just read the objectives when reading them the first time. Later, when you want to solve particular challenges you can read through the appropriate objectives more carefully.

These capabilities were not decided on via theory but by observing successful and less successful teams over almost 2 decades. Patterns of behavior were observed and recorded. While practices were significantly different, based on the context of the teams, the objectives achieved by successful teams were surprising similar.

Scrum as Example

Teams should never buy into a mindset of “just use it as is.” This is because “as is” may not be fit for purpose for the team. That said, it is often useful to jump in and start doing something. Scrum is sometimes a useful start. If you want to start with it, I suggest that you consider it an example of how you can do things. In other words, it isn’t the way, but rather a way.

You’ll of course need to learn how to change it so it doesn’t lose any value. Once you know how to do that, you can actually start quickly with Scrum and adjust as needed. This requires knowing:

• How to improve when you uncover impediments to delivering value in your organization
• What to do when you have challenges following the practices of Scrum

The power of Scrum as Example is that neither an organization nor any individual has to abandon what they know but can use their knowledge of Scrum as a starting point.

What to attend to while your read about the capabilities

While you read the “whys” of the capabilities you learn how good practices reflect universal principles. Over a little time you should gain some skill in matching practices to achieving alignment with these universal principles.

You can also attend to how well your teams are doing. I provide the following table to make a note of this as you go through things. This can be useful to see where improvement is needed.

Take a look at Table 1: Capabilities needed to do effective Lean-Agile at teams. Make a score from 1-3 where:

1 means you’re not attending to it

2 means you’re doing it to some extent

3 means you’re doing it well

Table 1: How well are you doing the required capabilities.

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