If you are running an engineering team and need to improve your delivery time, be more predictable, or deliver higher-quality code, this post is particularly for you. If this is not you, then hold on before you hit delete or click away. There are lessons to be learned for anyone that is managing or tracking your team’s work output.
It introduces four phases of agile process maturity and how to move through the phases. But first, a quick story about a client that I’ll call Joe.
Team in Trouble
Joe is the CTO/Co-founder of a startup, and in the past year grew his engineering team from one to six. He used to know everything going on with the team and his codebase. But in the midst of more customers, more sales prospects, and growing the team, he was getting frustrated because he could no longer stay on top of the day-to-day.
He continually lost track of the team’s work status. Blocked tasks were not visible and not getting attention soon enough. Delivery timelines, and thus the team, was suffering. He wanted more predictability and to be better able to estimate when new features and functionality would be ready.
As a result, he was thinking of implementing Scrum for his team. Scrum is a specific set of processes that a team can use to develop software. Scrum is a fairly opinionated process with many rules to follow.
At the time, they had little to no process. There are good reasons to implement more processes into your Development cycle, but going from nothing to Scrum rarely works. It's too big of a change. For small teams, Scrum is likely too prescriptive of an approach and creates too much overhead for a small team to absorb.
Instead of implementing Scrum, Joe moved the team through the phases I have outlined here.
Stages of Agile Process Maturity
Phase 1
Most new development efforts start in Phase 1. Ideas are going straight from someone’s head and into the codebase. Ideas may be sketched or written out in unstructured design docs first.
Phase 2
In Phase 2, you put all coding tasks into tickets that are tracked on a kanban board. Kanban boards are a simple and effective way to track the progress of work. You create columns that designate work status. As a discrete work task moves from one status to another, the ticket moves across the board. It looks something like this:
There are free kanban tools. Trello is a popular tool. Notion has a kanban board option. Popular tools that come with a fee are Kanbanize and Jira. For dev teams using Github, Github Projects is a great option. You can easily tie each ticket to a pull request. The screenshot above is from the open-source Github repo for ShapeShift.
If you’ve never used a kanban board before, you can start with three simple columns as shown here (this is from a free version of Trello):
You can expand as needed.
When starting in Phase 2, it doesn't matter how many details are included in the ticket. The first step is to start the discipline of not writing code unless there is a ticket to represent the work.
Gradually, the norm evolves so that there is enough detail in a ticket such that any developer can understand the requirements and do the work.
The process evolves such that created tickets don’t take too long to complete. A good starting point is if a ticket will take more than one week for a developer to complete, it’s probably too big. For tickets like this, start practicing breaking the work down into smaller tickets. The exact definition of what takes too long varies from team to team, and even project to project.
Phase 3
In Phase 3, before coding a new feature or functionality set, time is spent up front planning the discrete dev efforts. A separate ticket is created for each one. It is best if anyone who may work on this feature set participates in the work breakdown.
Individuals are then enabled to simply take the next ticket from the To-Do column when they are ready to start a new task. Less time is spent on “what should I work on next” conversations.
It is common for teams to review the tickets created for a given feature set on a regular cadence to determine if more tickets are needed. And if a particular ticket is deemed too big, it should be broken down into smaller tickets.
Phase 4
In Phase 4, it's time to get more predictable. This is easier than you think, as long as you are using tickets to track each bit of discrete development work and are moving tickets across the board as their status changes.
The first step is to measure cycle time. This is the amount of time it takes for a ticket to move from In-Progress to Done. That is, as soon as the ticket begins to be worked on, how long does it take to finish it.
There are kanban tools that measure this automatically and will report on average cycle time. If you need to do it manually, you can update tickets with a start and end date and then calculate the average.
Once you have these three variables:
Average Cycle Time
Number of Tickets to complete a feature
Number of Devs working on the feature
You can then estimate how long the work will take with this formula:
# Tickets * Avg Cycle Time * # Devs
The first time or two this is done, don’t commit to external dependencies based on the estimate. Measure the estimated date to actual date and make adjustments for your next estimation.
Adjustments may include:
Accounting for developers on vacation
Adding a confidence factor. For example:
We are 50% confident in this estimate
We are 80% confident in this estimate, plus or minus one week
During work breakdown, be conscious of how evenly sized the work in each ticket is
A Happier More Productive Team
Joe’s team is currently in Phase 3. Through this iterative evolution of their development process, Joe now has increased visibility into the status of work. Blocks are surfaced and resolved more quickly. The team is more responsive to changes and more quickly gets back to productivity when disruptions occur.
Joe now has more time to partner with his co-founders, grow the business, and proactively manage his team. And the team feels more like a team. People are working together and it is clear they are achieving a common purpose. Employees are happier, and so is Joe.
Comments