Improving Sprint Performance - Part 4
This is the fourth part in a series I am writing on sprint performance. In the first part, I explain why I focus on improving sprint performance, especially using velocity. For the second and third parts, I explain what I changed external to the team (product management, Q&A) and internal changes.
This part, I will go over how I started on this journey.
If you’re a manager, you can learn the philosophy I used to apply to your own situation.
This article will take you about five minutes to read.
Introduction
When I was an individual contributor, I didn’t take sprint performance seriously.
How long something takes? Who knows?? I don’t know. Solving the problem can be quick or slow, lucky or unlucky.
Starting out as a manager, I continued this view on sprint performance, because I was just on the other side as a contributor. I never was confident in knowing how much time it took to solve a problem. I may have just got luckier, especially on things I knew well.
As I have to manage a team of developers now, I have figure out how long it would take them to solve their problems? Well, that would be impossible as there are numerous variables:
People.
Yes, all the variables are people. They don’t know enough, they’re sick, they’re distracted, they’re in a rabbit hole, there’s dependencies, the list goes on and on.
When my manager told me my output would be the team’s output, not my own, I had to change my view on sprint performance. There will not be a direct correlation from my effort to my result.
This is one of the biggest hurdles I had to arriving at considering how to analyze the team’s sprint performance. Only with this shift in mindset, I would consider the following to be the key areas in how the team’s performance improved.
- Metrics
- Workflows
- Signaling
Easy & Consistent Metrics
One of the breakthroughs for this journey is the use of an easy and consistent metric to measure performance. Emphasis on: easy and consistent:
- Easy - to produce, to see, and to calculate. In my case, directly from the tool.
- Consistent - to calculate, everyone involved measuring performance the same way.
Easy Metric
When the metric is easy to produce, it’s more accessible. Everyone can see it for themselves, it’s not a “secret” that only one person has.
I mentioned earlier that I came up with my own method to calculate another metric. That became a job in itself, inaccessible to anyone, and calculating was more complex than anticipated.
Using a “standard” metric solves all of these problems. Standard metrics have a high chance of your project tool supporting it. At the same time, with standard metrics, there’s a higher chance of reading external literature on it.
Consistent Metric
When using a metric regularly, it helps with getting buy-in from everyone for any changes you want to have to improve, especially when using the metric as a guide. Applying the metric to past data to help estimate what’s going on now. Moving forward, calculating the performance in the same way from sprint to sprint.
Most importantly, everyone knows that’s the metric and can adhere to it moving forward.
First step in helping me understanding how to improve the team’s performance is have an easy and consistent metric.
Analyzing Workflow
This is an idea I got from Andy Grove’s High Output Management. Where analyzing the existing workflow, understanding each part of the process and who’s involved.
I took our workflow and found there are eight steps that involve four different people. (As I am writing this, I realize this would be another area to fix. That’s another article.)
For the current workflow, I compare the ideal and what actually happens with the stories by looking at how long the stories were in each stage of the pipeline.
This analysis brought revelations that work was not done in a linear fashion. Even though there’s eight stages, stories were bouncing around between stages. Main reason: “story kickback”.
Understanding this help me formulate solutions of increasing story detail, adding a technical grooming session, and redefining bugs.
Without comparing the ideal workflow and how the work is actually going through the workflow, I would not be able come up with these solutions.
Signaling
How do I keep problems small in my team? By having signals so I know when there are problems.
Without signaling from the team, I just don’t know if my team members are on or off track. Are they stuck doing discovery? Do they know their next step? Are they stuck and need help figuring out the best path forward?
Poor signaling has made hiding a problem for a long time that it became an all-hands crisis.
At the same time, I cannot poke and prod every team member daily.
I also want signals given to me useful to other leaders for visibility into the team’s progress.
With better signals such as: aligning status to story points, writing stand up reports, helps me bring solutions of technical grooming session for the group with individual pairing to keep problems small before the blow up into an all-hands crisis. (Trust me, it’s happened!)
This is how I keep problems small.
Conclusion
Who would have thought that figuring out how to improve a team’s sprint performance would require a change in attitude? It did for me!
Once my mindset went from: my output is my effort to my output is my team’s output, I view sprint performance as manageable.
How I am managing the team’s performance now is through:
- Signaling - to find problems when they’re small and fix them.
- Analyzing workflows - to keep sprint time focused on implementation.
- Easy and consistent metrics - to have an easy measurement of performance.
I’m still learning to manage the team’s performance and there’s new things to learn.