I recently saw a post from a friend of mine who’s very active in the Agile Denver community about “working toward better, not best”. And while I agree with the sentiment, I think there’s something that we tend to miss when we talk about continuous improvement and goals for teams. Each team’s version of best is going to be different than any other team’s version. So we should be working toward how a team can be their best, not some objectively-based best. What measures of team performance should we be using?

Evaluating a Team

One of the first things to do is evaluate the team. How are they doing right now? What does their team performance look like? We can use a variety of metrics to evaluate the team but we need to remember that these are about this time, not any other team. We can look to Lean concepts to help identify some basics of team performance.

I always look at the Cumulative Flow Diagram for a team over some period of time, say a sprint or just two weeks. This helps identify where the team may be exhibiting some anti-patterns. In my experience, the most common is violating some ideas around work in progress.

Another common pair of metrics from Lean methodologies are cycle time and lead time. Lead time (the measure from when an item enters the backlog to when it’s delivered) can be a bit misleading in a typical Scrum environment because of how backlogs are created and refined. It’s likely that we will have very high lead times while still being a high-performing team. Cycle time, however, only measures the time from when the team begins work to when they deliver – a much more accurate representation of how the team is performing.

The typical Scrum metrics of burndown and burnup can show how well the team is dedicating time to completing work. They can be “gamed” a little, though, so we should be cautious with burndown. Burnup, or the measure of work that’s delivered during the sprint, is a good measure of progress. We don’t want a team working to deliver everything at the end of a sprint. Rather, we want them to deliver (or even just have work accepted by the Product Owner) during the sprint when it’s completed. We don’t want hockey sticks for burnup charts!

These are all great ways to look at a team objectively to see what they’re doing. And while a team may be delivering consistently, we want to understand how they can improve. And metrics are going to give us the objective data that allow us to measure team performance properly.

Making Improvements

There are a few things that a coach can examine for helping improve team performance.

Make the Team Own It

First and foremost is to recognize that it’s up to the team to make the changes. I’ve talked about this before (many times) but it bears repeating. The best coach in the world can only point out ways that a team can improve – it’s up to each team to own their improvements.

Use Lean to Your Advantage

The second way is to use our understanding of Lean to focus on some first level improvements. The first thing to look at is going to be the team’s work-in-progress, or WIP. How much work is the team doing at one time? Small batch sizes work best, as we learned from Reinertsen’s . Limiting WIP helps us focus on working items to completion and then delivering the next set of work items. This is the essence of Scrum – working in short time frames and completing small batches. But even inside a sprint, the same technique can help improve team performance.

Cross-Functional For the Win

The third thing is to make sure that the team has all of the required skills to deliver the work. Oftentimes teams are more specialized in their function. Scrum (and agile in general) requires the use of what are termed “cross-functional teams” meaning that the team itself can complete everything from “soup to nuts”. In other words, no other teams or individuals need to be engaged to meet the need the customer has. One common situation is that teams rely on database administrators or developers to build out back-end portions that the team will use. Ideally, the team can manage that on their own. As coaches, we can look at adding those skill sets to our team to help improve our performance.

Sometimes Outside Is Better

Finally, determine whether bringing in an external coach would be beneficial. Sometimes teams react differently to the advice provided by an external person. Coaches bring a lot of knowledge and experience to their engagements and the interconnections that allow us to make leaps in team performance.

Regardless of where you begin, make sure that the team feels responsible for their own improvements. Guide, coach, and suggest, but do not – under any circumstance – tell the team what to do.

Working Toward a Team’s Own Version of Best

Each team is going to have their own version of what best looks like. One team’s best may be delivering a huge number of work items every sprint. Another team’s might be for high-quality work items. And another’s may be for blazing trails with automation and continuous deployment. Whichever path your team takes, they’re making the way to their own version of best.

@ Velocity

We are always working to find new ways to make improvements. We have a community of practice that meets weekly and specialists that help our teams tackle specific technologies or practices. With a growing number of Scrum Masters, we are starting a guild to allow our Scrum Masters to learn from each other. Overall, Velocity Partners is working to continuously improve not just our people but our processes and roles.

Closing Thoughts

Coaching teams to always look for ways to improve team performance is critical to delivering better software. Without it, our teams will flounder and do the same work the same way. While this is at least consistent and predictable, it fails to achieve the goals that we have for agile teams. Look at the different approaches I listed above – and look elsewhere too! – to find the right path forward for your teams.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)