Amplio@Teams 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@Teams 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.

Amplio@Teams Is a Patterns Framework

What is a “patterns framework?” To answer that question we must first answer the question “what is a pattern?” In A Timeless Way of Building, Christopher Alexander described a pattern as a “solution to a recurring problem in a context.” Each pattern has:

  • A name so that we can identify them
  • A situation (context) in which they apply
  • An objective includes a why so we can understand it’s purpose
  • A set of implementations that can be used to implement it

A common pattern in the Agile space would be “planning event.” It applies when a team or teams needs to plan what’s going to be worked on over some future amount of time. Its objective is to create a plan to work from so that the team(s) can coordinate their work. There are different implementations available – the Scrum planning event, the SAFe Program Increment Planning event, and others.

Different ways of meeting objectives are needed because no practice is universal. But substituting them may be precarious for those without deep experience. A framework of patterns specifies all of the roles and practices needed while allowing for implementations that fit the situation. We call such a framework a “patterns framework.”

Amplio@Teams is a patterns framework. It specifies all of the capabilities required to be effective at the team level. For each capability, a set of options are made available, enabling teams to pick the way to implement the capability that best suits them.

The Advantages of a Patterns Framework

There are two common ways of attempting to adopt Agile. The most common one is to adopt a framework or well-defined approach. Scrum is the most popular team framework. But most teams have challenges with it because Scrum was designed for early adopters in a cross-functional team, building a new product, and being allowed to self-manage themselves. This, unfortunately, doesn’t describe that many teams using it.

Many teams have decided to create their own process, but this is often expensive and ripe with risk unless they have some deeply experienced people involved.

Amplio@Teams being a patterns framework has the advantage of providing a well-defined approach that is fit for purpose. It does the leg work, so to speak, of what needs to happen while enabling teams to determine what works best for them.

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@Teams’ objectives are organized as:

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

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@Teams 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@Teams 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@Teams. 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@Teams: The Path to Effective Lean-Agile Teams


New Workshop

More Info >>

Upcoming Events