MELP #1: Development Workflow as a System
Many software development teams use Jira to manage tickets (either a task or a user story) and Github for code review (opens a pull request and invites team members to review).
As a manager or a team lead, it is challenging to track your team performance when you don't see the connections between ticket and pull requests.
In general, tracking completed tickets is a good start. However, sometimes one ticket can produce many subtasks and pull requests. The complexity is hidden inside your development workflow. You should see the development workflow as a system.
Development Workflow as a System
This system diagram illustrates the development workflow across the two platforms. Let me walk you through:
Ticket is the inventory of the in-progress tickets in Jira, including review and shipping stages
Pull Request is the inventory of the pull requests in Github
When engineers start working, the tickets move to in-progress based on the WIP Rate, aka Work In Progress Rate
Engineers open the pull requests for the tickets based on the Open Rate
Engineers close the pull requests based on the Merge Rate
The tickets are marked as done based on the Complete Rate
Cycle time is the elapsed time from the tickets moves to in-progress until it is done
Some observations from the diagram:
The higher the WIP rate, the more pull requests will be opened
When the open rate increases, the merge rate also increases
The more pull requests being merged, the more tickets being completed
That sounds about right until you look at the cycle time. Little's law states that the average cycle time is calculated as the ratio between WIP and throughput.
Average Cycle Time = WIP / Throughput
If the WIP rate increases and the complete rate remains, the cycle time will increases. Although you complete more tickets, it takes you a long time on average.
Pull request serves as a subsystem in the development workflow. The open rate is similar to the WIP rate. Cycle time of pull request increases when the open rate increases but not the merge rate. The subsystem's cycle time directly impacts the overall cycle time.
All metrics are directly and indirectly influence the outcome of the system. So, what do you track?
Circle of Influence - WIP Rate
Circle of Influence implies the things that you have direct control over. WIP Rate falls inside your Circle of Influence.
Average Cycle Time = WIP / Throughput
Based on Little's law formula, the simplest way to complete tickets faster (shorter cycle time) is to reduce the WIP rate.
What about the throughput? Let's say if we manipulate the Little's law formula to formulate throughput:
Throughput = WIP / Average Cycle Time
To complete more tickets (higher throughput), you'll have to increase the WIP rate.
The goal here is to maintain a healthy WIP rate. If your team is suffering from the long cycle time, reduce the WIP rate but not too low until it causes throughput to reach an unsatisfied level.
In another word, the WIP rate is your leading indicator.
Circle of Concern - Complete Rate and Merge Rate
Circle of Concern implies the things that you have indirect or no control. Merge rate and complete rate fall inside this circle. Those are the metrics that you concern about but you don't have direct control of.
Merge rate is the less obvious but important throughput metric. Besides writing code, software engineers usually spend the most time reviewing code. Improving your code review activities causes a positive impact on the complete rate. Merge rate can be seen as the leading indicator to the complete rate.
Complete rate is the obvious throughput metric in this system. Your development team may have a different practice or workflow than others. Regardless, the complete rate reflects the overall performance.
Merge rate and complete rate are the lagging indicators.
Optimize For Healthy Balance
An optimized development workflow maintains the throughput and cycle time at a satisfactory level.
Optimizing for either throughput or cycle time without another, the system becomes imbalanced. It brings negative impacts to your team and organization, such as burnout or misses the deadline.
The optimization strategy is setting a WIP limit. Your team members stop working on a new ticket when they reach the WIP limit and start helping other team members. This creates a fast flow of development cycle, also encourages more team works and knowledge sharing.