After looking at the Ticket Log, the team lead switches over to the Work Log report, which provides an overview of the team activity broken out by individual. They don’t use this view to act as a “big brother” but to see if there are areas where they can help. Leaders can catch blockers that arise for developers and better assist with anything that might prevent them from completing their work.
Every task or data point within these reports has context. Perhaps someone is working on a ticket that doesn’t require a lot of code and is completely okay. The purpose of Flow reports isn’t to monitor every action but create communication around that context and build a better overall developer experience.
How do Pluralsight teams use Flow?
The team starts with the Retrospective report to review how the collective group is succeeding over time. They set their filters for the current quarter, compare it to the previous six quarters and look at data points, such as median queue time, to see how quickly things are getting pushed through the queue. A year ago, items sat in the queue for an average of 118 hours. Now they’re completed in less than a day.
The team accomplished this by having conversations during retrospective meetings after each sprint. They would pull up the Retrospective and Sprint Movement reports to find patterns and resolvable bottlenecks and better understand the cause of slower times (e.g., team member onboarding or upskilling).
They determined they had too many tickets open at any given time, which caused their queue and cycle times to be higher than they wanted. Using the Flow data connected to Median Queue Time, they discovered that a fair amount of their queue-time issues were occurring because of tickets awaiting review or action by other teams—so they adjusted their scoping and expectations.
By looking at the Retrospective and Sprint Movement reports as a part of all sprint retros, the team built out processes that allowed their metrics to improve, then stabilize. Because they are now in a healthier place with their processes, they focus their efforts on outliers. If cycle or queue time dramatically increases, they can instantly look into the spike and quickly resolve underlying issues.
Pluralsight Flow’s team leads recommend that organizations using Flow perform a value stream mapping so they can determine the steps it takes to get a piece of code through the production process. By doing this, you can build in the knowledge of when things may end up sitting in various queues or need further validation. You’ll better understand the data within the Flow reports and ultimately become more collaborative and efficient.
As Flow users, the Pluralsight team noticed that everything within the software development process is interlinked. By creating better lines of communication within and across teams, they’re able to have lower cycle and queue times, which increases velocity. As you use Flow more frequently, you’ll notice that some metrics are more tightly connected but, on balance, everything is connected. You’ll push products and features through the process faster, complete more tickets and improve overall team health and the developer experience.