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

This lightweight approach gives teams a way to start Lean-Agile in a non-disruptive manner that illustrates the fundamental principles of Lean-Agile. A case study is presented after it to facilitate understanding. 

Having a lightweight approach enables a team with no Agile experience to get started. More importantly, it provides a core set of concepts that can be used to continue to improve.  But it must be more than intentionally incomplete, it must be intelligently incomplete. That is, its core starting methods must include a way to improve as you learn. Edgar Schein’s maxim – “we don’t think and talk about what we see, we see what we are able to think and talk about” implores us to use a method that is self-expanding.

Amplio Light is a lightweight approach to getting a team to be more Agile.  It is a subset of Amplio Development, being based on the same core principles. These core concepts are sufficient to get started but lead us to richer concepts when needed. This enables us to start quickly while being able to access additional concepts as needed. This avoids overloading people while avoiding stagnation.

The essence of Agile is delivering value quickly by focusing on working on small items while getting quick feedback to both learn what’s needed and how to build it. A key to this is avoiding overloading teams. This requires teams pulling their work from a backlog when they have capacity.

Consider how much of your organization’s work has been due to:

  1. Misunderstanding requirements from the customer or product owner
  2. Writing stories that implement the wrong functionality
  3. Development errors that were not detected for a long time
  4. Taking a long time to fix errors because they were detected well after the time they were made
  5. Having a misunderstanding between teammates that results in handbacks and extra work
  6. Multi-tasking

Now consider how getting feedback at all levels of work would help with these. A simple step to achieving this is to see what you could complete that would provide feedback on what’s been done instead of starting something new. Taking a set of simple concepts that work together enables you to have a lightweight, fit for purpose, easy to learn solutions:

  1. Do what it takes to eliminate delays in your workflow, as these will slow down work, delay value delivery, and magnify the impact of errors.
  2. Organize your people into a cross-functional team. The team should have sufficient domain knowledge and skills to create the product. This includes discovering what it needs to be.
  3. Create a product backlog that contains the requirements of what needs to be provided based on what’s of value to both customers and other stakeholders
  4. Work on small batches of work that provide value, preferably no more than one week’s worth. Only pull work from the backlog when you have the capacity to finish it. Too much work creates delays and waste.
  5. Build your work in a high-quality manner. If the product is software, then build it in small end-to-end slices. Don’t put in extra code to make it changeable, but consider how the code may need to change.
  6. Get an understanding of how the person specifying the requirements will validate them. At a minimum, when a requirement is given, ask, “how will I know I’ve done that?”
  7. Try to avoid handoffs. When necessary, the people involved should have a conversation about the work. View handbacks as having done an improper handoff and make corrections for the future.
  8. Focus on achieving quick feedback by keeping the amount of work-in-process within the team’s capacity. When someone finishes something, have them help finish something that has been started already before starting something new.
  9. Finish a feature before starting another feature. Finish function that’s part of a release before starting part of another thing that will be released later.
  10. Agree when to meet to review how well the way you are working is going. When a challenge comes up work on solving it immediately.
  11. Have all work be visible and the way you’re working together be explicit

You can start applying the above to any approach you are taking.  The key is to observe when delays and handbacks occur. Notice how these cause extra work. Unplanned work. Wasted work. We want to avoid these delays and handbacks. The first step is seeing them. When visible, many of these delays can be eliminated. Some common delays are the time from when:

  • you get a requirement until you use it
  • a misunderstanding happens, and it is discovered
  • a coding error is made until it is detected
  • an agreement is made between teams on how to integrate and when integration starts
  • work is started on building a release until it’s completed
  • work is started on a feature until it is completed
  • work is started on a story until it is completed.

Take a few minutes for each and reflect on why these delays create additional work or risk.

 

Four factors to consider when starting a new project or initiative

There are four very important factors to consider when starting a new initiative:

  1. What is the degree of disruption the people involved can tolerate
  2. How much change is ideal
  3. How fit for purpose do your new practices need to be
  4. How people work together

People often confuse disruption with change. They are not the same. When coming up with a new way of working, let’s use the term change to refer to how much we are changing how we work. We’ll use disruption to mean how much our current methods are adversely affected by these changes. Thinking of change and disruption this way, we see we want change, without disruption.

Changes that improve our workflow are good. While these may require disruption, we prefer to minimize it. We must attend to the fact that the opportunity for disruption changes over time

One must be cautious when one applies a fixed set of practices. Two potential problems occur. One is that the end result may not be fit for purpose. The other is that the path to get there may be more disruptive than needed.

Systems thinking tells us that not having a fit for purpose solution will cause more disruption than having one. Disruption causes resistance.

The idea that less process is always good is mis-guided. There there is good process and there is bad process. You may want more good process. You definitely don’t want any bad process. But process itself is neither good or bad.
Process that helps people is good. Process that doesn’t is bad.

For example, the checklist a pilot uses on a plane before takeoff is a good process. if we think process is bad, we won’t find good process. Amplio uses the term “workflow” because it’s a less loaded term.

Specifying that we should have explicit agreements amongst ourselves as to how to work is a kind of process. if you focus on improving people in a bad system you likely won’t get good results – the system will remain bad, putting down the people

If you impose “improvements” on a system without including people you’re likely to make the system worse. Bad systems defeat good people. The role of management is not to manage people, but to help manage improving the environment that people work in. Ppeople often don’t do this on their own. They often don’t want to. They want to do what they consider to be their real job.

When we are about to do some improvement initiative, we should ask:

  • how disruptive can we be?
  • how disruptive should we be?
  • how fit for purpose are these changes?

Not asking these questions is risky.

Having a focus on workflows without a focus on people won’t get you a good working environment Having a focus on people without attending to how they can work together won’t get you a good working environment You need both. This is an example of systems-thinking.

Having a great customer focus without a great system means the customer won’t get value. Having a great system without a customer focus means the customer won’t get value. You need both. This is systems-thinking

Is a focus on how people are working together a focus on people or on their workflow?

You can’t separate these two.

Quick decisions to make before starting

Before starting it is a good idea to do the following:

  • get clear on the value you are wanting to create and the stakeholders involved
  • decide on whether to use timeboxing or flow
  • decide how to handle problems come up – wait for a pre-specified time at the end of the timebox or meeting immediately (recommended)
  • take 30 minutes to an hour to do a pre-mortem
  • decide on a definition of done
  • agree on classes of service

All of the above can be achieved in a 2 hour meeting. Recognize you may change them when you see better alternatives.

A Case Study

This case study is provided to give a specific example of the above. It was based on visibility, explicit workflow, a focus on deliverable chunks of value, and immediate solving of challenges. The author was involved in this project.

Context

A cross-functional team of four people were creating an e-learning workshop. Two were primarily knowledgeable in the content while the other two were responsible for building the actual delivery material.  One person on the team had a more profound experience than the others. He was considered the subject-matter expert but took no authority over what content to put in. He, and the rest of the team felt better content would be achieved via team consensus.

Agreements made among team members:

  • No one had authority over decisions, but they would be made as a group.
  • Schedule daily discovery and fix sessions. Each was scheduled for an hour, but if there were no issues, we wouldn’t hold them. When held, the meetings had two parts, the first a quick session describing the issues (5-10 minutes typically), with the second being a meeting to fix them. Only those needed would attend. This enabled identifying issues and immediately addressing them. This more extended segment would only take place when needed.
  • When a problem was found in how we were working, a quick meeting would occur if it could be solved immediately with appropriate people. Otherwise, it would get discussed in the next daily meeting.
  • All work was to be visible using Kanban-style boards were used to see where everyone was with their work.
  • We had a weekly cadence but worked in a flow manner so if we wouldn’t fall prey to having the work fill the time available.
  • We would interact with customers as much as possible.  

The net result

The project proceeded on schedule, within budget, and with the quality we were looking for. Retrospections on work and the way of working typically happened 2-3 times a week. Everyone felt that they could contribute and there was never an appeal to authority.

The less experience Agilists on the team learned a lot about Agile. The more experienced people learned how to convey Agile concepts.

 

Contrasting Amplio Light with Scrum

The biggest differences between Amplio Light and Scrum is that Amplio Light can be slightly tailored at the start and make additional practices available when they are needed. This makes Amplio appear to be just as simple as Scrum at the start, but enables it to grow as needed. The tailoring, however, enables it to be more fit for purpose and therefore simpler to adopt.

Amplio is a very rich system. With connection to hundreds of options that are made available as needed. It can start out as simple as Scrum by providing only a few of its practices – and not going deeply into even those. The trick to being simple is not to have a limited system as much as it is to not overload teams.

Scrum is not so much simple, as it is minimalistic. This requires people to reinvent practices. Also, because Scrum does not present first principles, or how to change practices for more appropriate ones, teams often struggle when what they need conflicts with Scrum’s prescribed practices. Even when there is no conflict, Scrum practitioners have to re-invent the wheels that Amplio provides when needed.

Scrum being immutable is not the problem. It’s a symptom of the problem – that Scrum isn’t based on first principles and provides no method of telling if a change to a practice is an improvement or not. This locks people into it and requires the inspect and adapt routine which is a lot slower than having a solid theory to work off of.

Scrum and Amplio Light are both easy to start. “Training” on Amplio took a couple of hours.

Amplio Light is often more fit-for-purpose than Scrum because it allows teams to decide how to achieve their objectives while Scrum requires using some practices that don’t work well everywhere.

Amplio Light’s core provides guidance on how to continue to improve by using first principles. Scrum insists on practitioners following its immutable roles, events, artifacts, and rules and provides no set of first principles to use.

Amplio Light never suggests to follow it. Rather it is organized around easy to understand objectives. Practitioners are encouraged to meet the objectives any way they can that works for the team. Scrum requires many practices to be achieved regardless of how well they fit the team or if there are easier ways to achieve the same desired result.

Amplio Light heeds Edgar Schein’s warning about not seeing what we talk about by being intelligently incomplete instead of just intentionally incomplete. Its focus on first principles and quick value add illicits conversations about alternative methods of removing impediments. The book this chapter is a part of – Amplio Development: The Path to Effective Lean-Agile Teams – also provides a reference for what else may be needed.

Amplio Light is focused on continuous learning as opposed to learning at the end of the timebox.

 

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

Go to Being a Professional Coach

Latest Article

Why Leaders Should Focus on Value Streams

Read on Cutter's site >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow

Watch Video >>

Upcoming Event

The Amplio Community of Practice (Free)

Learn More >>

New Workshop

The Amplio Development Masterclass

More Info >>

Latest Presentation

Intro to BLAST and How To Solve Challenges in the Workflow