In the four years since I wrote "Why you may need an agile coach," a few things have become abundantly clear. First, as the article laments, the question “What do coaches do all day?” is not really answered in the literature or community. The article does not come up with a strong answer either, implying the coach needs to adjust his approach to fix whatever needs to be fixed.
Fifteen years after the release of the Agile Manifesto, “being more agile” isn't the goal. At least, it shouldn’t be. Neither is “doing DevOps,” or even “doing continuous delivery.” Instead, the goal should be to deliver business value. Here's how coaches can do just that.
Getting started: One goal at a time
When my organization works with teams, we typically tackle one goal at a time. That might be to improve the pace of delivery, to release more frequently, to speed up the test/deploy cycle, to reduce the number of defects escaping to production, or to reduce the time it takes to get a fix into production.
When I talk to management about being more agile and ask them which of those things they want, nine times out of 10 the response is, “That all sounds great.” In other words, they want everything.
It’s hard to make progress toward improvement with six goals at once, especially if no one has decided how to measure them.
To find the goal, we often do an analysis of the existing delivery cycle. That means considering how long things take at every step, whether there are any easy tweaks the organization could make to improve, whether there are any radical changes they could make for radical improvement, and whether those changes will fit culturally.
After that, we bring that data, with numbers, to management so they can decide if coaching is a good idea.
Fixing the isolation problem
It’s tempting to look at a software organization as a consultant might look at a bicycle. Identify the component pieces, find a cheaper way to make each component, put it back together, and—boom—you’ve reduced costs by 50%.
Just like a real bicycle, software delivery is a system. While each component might be 50% cheaper and seem to work in isolation, the whole might fail. The parts might be cheaper, but they also may be cheaply made, so the bicycle might break under the weight of the rider. In software, you’re likely to see delays and failures that need to be reworked, eliminating any savings from this kind of approach.
The analysis above is more about improving capability over time than hourly cost savings, and that kind of improvement is generally based on skills development. In the technical ranks, the improvement will probably involve using more modern tools, but it is likely to start with how you approach the work. Not “use cases instead of requirements,” but better requirements. Not switching to Python tomorrow, but better coding today.
Many “coaches” focus on running the meetings, and there is nothing wrong with that. The question is: What is the goal, and how will the activities of the coach track toward that goal?
A day in the life of a coach
In his book Toyota Kata, Mike Rother explains that without a target condition, or goal, “improvement” becomes what the loudest, most persuasive voice can argue in the moment.
Once the team has a target condition, the coach helps the team build skill and change process to adapt to that target condition. For example, if the goal is one release per week and the ability to test/fix/retest to releasable software within one business day, the coach would invest time in teaching, pairing, and facilitating to help the team reach the target condition. Here’s what that might look like:
- Attend daily standup.
- Perform one hour of mob programming.
- Work with product owner and a technical staff member refining stories.
- Pair for four hours with a programmer to help him develop code craft skills.
- Listen for performance problems and help the team resolve one.
- Pick an infrastructure backlog task and pair on it.
- Run the weekly book club (or lean coffee meetup.)
- Meet with and attempt to resolve constraints and delays outside of the team.
- Help the team engage in retrospective thought and commitment to improvement.
Coaches have many ways they add value to an organization. With the target condition in mind, the coach can pick something to say yes to, instead of trying to fill up an eight-hour day with work. Along the way, the coach’s goal is to make himself obsolete—to build the skill within the team so that it can manage its own work.
This is the kind of work that a good technical lead will do, but a good lead is focused on production, and generally to one specialty. A coach is focused on the whole team, does not have any HR authority, and is generally brought in to focus on deliberate practice or build a skill the team simply does not have, such as continuous delivery, test-driven development, or highly effective pair programming.
Nontechnical coaching
Most organizations start out with technical barriers to delivery—or at least they start out believing this. Technical coaching can accelerate delivery so much that the organization begins to see the rework, the waiting for decisions and dependencies, and the inconsistent priorities. But further technical coaching will not solve these problems.
At this point, the bottleneck has shifted to the business, to inter-team coordination. It’s likely that the bottleneck was always outside the team, but multitasking and other behaviors hid it.
A program coach, portfolio coach, or executive coach performs in a similar way to the technical coach, providing training and deliberate practice. The activities are similar, only instead of code, the leadership team might be looking at a spreadsheet of projects or data on the performance of a project. The book club is more likely to be Toyota Kata than Design Patterns, and pairing activity will be in working together to make better decisions instead of writing code.
The value of coaches, whether technical or not, lies not in the answers they give, but in the questions they ask. Just as a good tester knows how to provoke and elicit information from a system, a good coach knows how to provoke and elicit information from people. The differences are that software can’t solve its own problems when provoked, and sometimes all people need from a coach is the right kind of provocation.
Now make it work
Adding a new role in a software group is a risky proposition in that it tends to create hand-offs and specialties. Having someone in a specialist role usually means that someone with a certain kind of expertise is needed to do the work, and that can create delays when that expertise is unavailable.
Coaches don’t always work like that. They tend to be broadly skilled and can do many different things, acting as “floaters.” Coaches should be temporary, designed to build up the capabilities of teams in specific areas sufficiently for them to sustain the benefits learned from coaching.
Given the right goal, the calculus for a coach should be clear. Eliminating the regression test cycle, for example, reduces so many weeks of running in place per year, which has so much of a concrete cost, and the new software delivered has so much new value.
So the next time someone wants to bring a new specialty into the team, for example, a performance, security, or accessibility testing engineer, consider making it a team responsibility and coaching them on how to integrate that knowledge.
You might not have a coach do that work, but at least you’ll understand how they would do it, as well as the value a coach can provide.
Jonathan Bach and Wouter Lagerweij also contributed to this article.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
