One big problem with high-velocity agile teams is the inability to make a permanent change.  That’s the kind of change where a team continues to execute with new and helpful behaviors rather than moving backward after they’ve gone through the  Yipe!->Quick Fix->Regress Cycle.

As an Agile Leader you want to help your teams resolves issues perpetually or as permanently as possible rather than revisiting them sprint after sprint, month after month or release after release.

A couple of recurring issues crop up on my teams.  First, increasing Amazon Web Services (AWS) cost in development environments; second, lacking enough automated tests to maintain team velocity and third, finding the balance between too much refinement in a story before grooming vs. too little refinement.

In this article, I’m going to walk through concrete steps to create permanent change using the example of increasing AWS costs in development environments.

Step 1: Realization

For most teams realizing that specific areas need improvement is evident.  Most of the time this realization occurs when bugs propagate into production system or when the Product Owner (PO) and team members thrash over requirements or design.

The typical agile retrospective exposes many problems and in some cases too many problems to address at once.

In the case of AWS Costs, this had visibility up to the customer.  The cost was consistently running over the monthly budget, and it wasn’t clear how to fix it.

Step 2: Focus

In the AWS example, the team looked at the infrastructure and realized there was a sizable amount of technical debt.  Team members suffered stress as they reviewed the ambiguous and daunting task before them.

Applying the how to eat an elephant story provides perfect anecdote in the face of this enormous journey.

“Question: How do you eat an elephant? Answer: One bite at a time”

The Chinese proverb about travel might also be applicable, “A journey of a thousand miles begins with a single step.”

Focusing on a single step is the foundation for a team’s success.  Getting overwhelmed will result in the sense of doom and a team may stay frozen in time.

Practically speaking, if a retrospective uncovers numerous items, I will insist the team pick one item. Teams often want to solve every problem at once, but it’s not only impractical, it’s starting a team down a path of never solving any problems because they spread their energy over too many problems.

In Lord of the Rings, Fellowship of the Rings Bilbo Baggins says to his wizard friend, “Gandolf, I’m feeling stretched thin, like to too little butter spread on a piece of bread.”  A team will feel the same way if they take on too many improvement tasks at a time.

Once you’ve put the focus on an initiative, how do you know when you’ve made progress.  For small and easy efforts getting to done requires very little contemplation.  But the type of initiative this article addresses requires a long-term effort and some way to keep track of progress.

Step 3: Measure

One of my favorite visionary authors, Peter Drucker, said, “If you can’t measure it, you can’t manage it.”

The 19th-century scientist William Thompson, also known as The Lord Kelvin, states, “To measure is to know,” and “If you can’t measure it you can’t improve it.”  The absolute zero temperature scale was named in Kelvin’s honor thanks to his contribution to science.

One of my former bosses used the following mantra and quoted it to us regularly.  I don’t know the source, but the statement packs a punch.

Measure to know, know to change, change to lead.

The measurement of sprint velocity remains the most prominent tool for teams to understand their capacity for work.  Now it’s time to apply that same lever to other aspects a team’s behavior.

Making measurements visible will help keep energy and focus on the area that needs improvements.  Pick a measure (graph or chart or single number) and show it either every day at standup or every sprint review.

Now that you’ve decided on a measurement, how does a team decompose the goal into workable chunks?

What if I’m starting from zero and the one issue consists of a massive change to the system or significant process changes?

Let’s endeavor to break the problem down even further to enable the team to start small and end big.

Step 4: Plan

I’m not sure where our upbringing or school or training failed us, but sometimes we just don’t want to iterate, we want to do everything.

I’ve met only a few technical leaders and software engineers who consistently plan in an iterative fashion, and I know why.  It takes serious mental effort and sometimes out-of-the box thinking to break down a problem in small end-to-end chunks.  It’s much easier to think of the problem in components or modules.  Finishing each component gives a sense of satisfaction to the engineer or leader, but risks are not retired until all the components get integrated.  The pain of iteratively building each component might incur an extra cost because each component needs refactoring along the way.  But the alternative of big integration after independently developing the components has high cost and usually more pain.

The iterative planner starts with zero and finds the riskiest piece of the problem and then builds outward sprint after sprint retiring risks and ultimately completing the project.

As an Agile Leader, you dig in deep to understand the technical aspects of the problem which faces the team. Gather information by interviewing the team members or technical leads. Write down the outcome desired and then in a spreadsheet or document make an iterative plan based on your educated guess.  The outcome statement and associated iterative plan give a framework to discuss with your team.  An empowered team will create an iterative plan for themselves. With tough issues, having a template will give the Agile Leader a robust framework to coach the team.

You’ve done your homework, you have a plan, and now you need to engage the team.

Step 5: Implementation

Depending on the size of the problem, either hold a meeting dedicated to the specific of the problem or just add a couple of stories to the backlog. Yes you need permission from the Product Owner, but these stories do provide customer value in a roundabout way, so you’ll justify these items by demonstrating the long term value.

Holding a meeting won’t necessarily result in a positive outcome unless the meeting has a clear focus and the collaborative event is well-managed.  See articles on meeting facilitation for details on how to keep collaboration productive:

Agile Leadership with Facilitation = Hyper-Productive Teams

Agile Leadership with Facilitation = Highly Focused Teams

Agile Leadership with Facilitation = Fast Decision Making

Not all issues require significant facilitation to solve, but if the issue has emotional energy such as code reviews or unit testing, the Agile Leader will likely need a rigorous plan to keep the team on target and away from distracting bias.

The outputs from the implementation step are action items and backlogs items. And make sure you have a small step.  Small steps result in success and make the cost of technical debt digestible for the Product Owner.

Put the first backlog item into the upcoming sprint and execute.

For the AWS cost reduction effort, the team’s initial action was to audit and shut down any lingering instances that were not actively in use by developers, UAT or Production.  They found a few hundred dollars worth of idle components.

Step 6 Tracking

Review progress at sprint review, retrospective or if it’s critical at standup every day.

It’s good to see progress.  Hopefully, the measurement resonates with the team and with the Product Owner.

Celebrate your success when the measure shows even slight improvement.   Use your retrospective to examine the progress and groom the next steps you’ve laid out.

During the AWS cost reduction effort, we put cost metrics in the sprint review presentation, and within a couple of sprints, the cost was under budget by 30%-40%.

Consistently show the measurement. Don’t show it one sprint and drop it the next.  Consistency results in focus, which results in change.