It’s inevitable. People get behind.
As an engineering manager, one of your key jobs is making sure that the development pipeline is flowing smoothly. However, it’s not always easy to see when it’s not.
Usually, I find out after a few complaints that “QA is holding up everything”, or “Analytics is taking forever to get us the requirements”. It only comes to my attention after the delivery timeline is threatened, and the pressure is on.
It takes skill to navigate those situations, and, of course, it’s likely to lead to a not-so-fun conversation with your boss about the timeline.
But, we can actually take some preventative measures by looking at trends in your data.
For the rest of this post, I’m going to discuss some examples of management failure that we’ve seen using real data from the Allstacks development team’s process. We’ll take a look at understanding bottlenecks and issues using the data from our Active Issues metric, which shows the number of issues you have in each development status for a project across all tools that are connected (i.e. Github, Jira, and Trello)
Let’s start with the dark blue line across the bottom of the graph. For our team, that’s our in progress state. This is the number of active issues our developers are working on at any given time. As you can see this state is pretty static. Our developers can only have a few items on their plate at any given time because there are only so many hours in the day. In some management strategies (like Kanban), this state is restricted by design to only allow a few items here, but our team is limited primarily by our capacity. It’s what we have to work with, and it’s clearly the limiting item in the flow.
Let’s observe where the problems start: In the first image, we’re showing all of the intermediate steps (those between start and end) in our development workflow (we’ve simply hidden the rest.) I’ve highlighted two items, the red arrow and the green arrow that are both trending up. What we can see here is that issues are piling up in these two states: “Requirements Complete” and “QA”. That’s not good a this is where the slowdowns begin.
Since this was our own team, we can share some extra insight into what was contributing to this scenario:
- At the beginning of the rise for the red arrow, we had just released the beta product. The majority of these newly created items were all of the bugs we found after putting our product into the hands of customers for the first time. Leave it to customers to find creative ways to break your software.
- Consequently, we had a lagging spike in our QA phase. Since our CTO (me) was solely responsible for QA, at the time, this increase in bugs was quickly overwhelming. That, compounded with continuous context switching between a customer success and development led to a delay in shipping new features and bug fixes.
We were eventually able to get caught up, and now we are managing our feature and bug burn quite a bit better, but as you can see, we lost productivity for a period of time. Taking a look at the number of issues we have been completing over time, we can see that we didn’t continue our momentum from project creation. So, while we were able to catch a problem before it seriously hurt delivery, we can actually see how we could have performed a little better had we been better resourced in our QA function.
It’s important to keep track of where the bottlenecks are in your team. They can come in many different forms, and from many different sources, but one of the key early indicators of a bottleneck approaching are issues piling up in a particular state.
To learn more about how to get this data, and how to automatically generate these insights, contact us to learn more about the Allstacks platform or email us at email@example.com!