“This process is working.” “These numbers are down.” Every organization needs set measures to see how they’re performing relative to goals and expectations, but yours have to make sense.
Metrics are a contentious topic, too. They can be used for continuous improvement, but they can also become a collective yardstick for comparing teams. The problem is that the latter can prompt leadership—managers, directors, VPs, and executives—to say, “We need this team to work harder.”
How do you bring out the best across the organization? Read on as we explore the value of metrics and how to implement the right ones to create effective and Agile teams.
When you choose performance metrics, you need to provide a way for leadership to understand when teams are struggling so they can resolve impediments and offer support. Of course, this means finding the right mix of metrics to inform leadership, without creating a culture where teams feel like they’re being micromanaged.
Your metrics shouldn’t make life harder for you or your teams. Instead, they should be easy to implement and reveal opportunities. Make sure your metrics have three characteristics:
Each is lightweight.
Each is easy to measure.
Each exposes improvement opportunities for teams and leadership.
That last one is especially important because leadership isn’t used to being measured alongside development teams. By factoring leadership into the equation, you shine a light on where they could provide better support and create dual accountability.
What leads to high-performing Agile teams? Think about business in general, but also about your teams in particular. Several factors may influence whether they are as effective as they can be, including:
Cross-functionality
Team size
Co-location
Which product owners are available
Working agreements
Regular team outings
Direct access to end users
Take the time to iterate on and refine your list. I did this during a particularly challenging project, and it significantly improved the process. Here’s a breakdown of my approach:
I started with a list of about two dozen items—leading indicators into high-performing teams that could help influence change, rather than simply record what happened. The items were binary, with either “yes” or “no” answers, helping to quickly and easily tally a score.
When you take this approach, you may include these or similar questions:
Yes/No: The team has 6 or fewer developers.
Yes/No: The whole team participates in the retrospective.
Yes/No: Work is visible.
Taking this approach helped me, and It could help you, too. Here’s a larger breakdown of the indicators I used, which could be applicable to your needs as well.
Note: Be sure to distinguish which items are controlled by each group!
| Team Can Control | Leadership Can Control |
| Team is cross-functional | Team is cross-functional |
| Team has and respects working agreements | Dev team has six or fewer people |
| Team has and respects the definition of “ready” | Dev team is fully dedicated |
| Team has and respects the definition of “done” | Team is co-located |
| Team uses WIP limits | Team has one product owner |
| Team has direct access to users | Product owner sits with the team |
| Whole team participates in retrospectives | Team has one dev manager |
| Team outing took place last quarter | Team has one Scrum master |
| Team has backlog items for upcoming release | Scrum master sits with the team |
| All backlog items are estimated | Team members have not changed in past month |
| At least two sprints worth of backlog items meet DoR | Team has direct access to users |
| Work has been showcased in the last month | Team outing took place last quarter |
| Work is visible on some board | Team had input into the targeted completion date |
| Work is assigned prior to coding |
After you choose the most suitable indicators, answer yes or no to each and assign points: One point for yes and zero points for no. Add up all points and divide that number by the total possible to determine a score.
After each sprint, record the numbers for teams to see. But remember that the hard numbers aren’t as important as the trends they reveal over time. Is the HPE score going up or down? During my own experience, I found that a downtrend could reveal opportunities for teams and leadership to make a change, while an up trend could indicate you’re on the right path.
With a clear picture of HPE, you can better discuss continuous improvement and organizational impediments. That’s because, with trends in hand, it’s easier to raise issues to leadership and find solutions to create high-performing, Agile teams.
Examples:
Management reduces a team from 12 developers to six, leading to better communication and collaboration.
Teams start using their working agreements and definition of “ready,” leading to better alignment.
HPE metrics can be the key to creating Agile teams within your organization, providing a forward-looking indicator of how to set them up for success—both from a team member and leadership perspective.
Keeping a keen eye on established metrics lets you know when your organization is headed in the right direction or if there’s room for improvement—and where. But you can’t pick a few at random, nor should you be heavy-handed and create a negative culture.
Take steps to balance your approach by considering which aspects have the most power to drive your teams and overall business forward. Use this as a guidepost for getting started, then schedule a meeting with Project Brilliant to learn how to put the pieces in place to create more Agile teams.