This series of blog posts focuses on predictability. Can your team deliver results when business needs them? Can your team keep deadlines and gain the trust of your customers by being reliable? You can find the first two parts here:
Workflow is the process that a company uses to get things done. In software development, it’s a process that creates software, from early specifications all the way down to production deployment. While it is not a secret that software development is often chaotic, there are ways to make it more predictable. Or at least a bit more predictable as it used to be, by applying some small incremental improvements.
As a team, your goal is to to ensure fast, predictable, and uninterrupted flow of planned features that deliver value to the business.
I've emphasised the word planned because in order to be predictable, you should aim at maximising the amount of planned work while minimising the unplanned work like bugs, server crashes, rework, and all the other surprises that come along. You know, firefighting.
Easier said than done? You bet. But there are some easy wins you can gain by visualising and quantifying your workflow. You'll get new insights that will help you to identify and remove bottlenecks. By doing so you'll be able to deliver great software faster.
Visualise the flow of work
Start by visualising your workflow. Find a stack of post-it notes that you can stick on a wall and place them in columns like these.
On the board above, cards move from left to right as work items move from one workflow state to the next.
Once you’ve made your workflow explicit, you can start looking at inefficiencies and bottlenecks in your process. Here are few things you might want to pay attention to:
- Are some tasks staying too long in process before being completed?
- Are some steps in your workflow painstakingly slow?
- Is work piling up for a certain person or workflow state?
You may want to limit the number of cards in each state by introducing work in progress (WIP) limits:
Setting limits to the number of task can feel counter-intuitive at first but soon you realise that when there's less context switching it actually means you complete your tasks quicker. You'll feel better as there’s less hassle and task juggling in your workday.
Quantify your workflow to find opportunities for improvements
So how do you quantify your software development process? Well, first you need to decide what metrics you’re interested in. A good starting point is to start measuring your team's velocity and cycle times.
Velocity is simply the amount of work completed per iteration, or some other unit of time. Your team's velocity tells you how much work they could include in an iteration, based on how much they have completed in past iterations. For example, if the team completed 10 tasks in the first iteration and 15 tasks in the second iteration, then the team's average velocity is 12,5 tasks per iteration. That number can be used as a guideline when choosing how many tasks to include in the third iteration.
Cycle time is the time it takes from starting work on a task until it's ready for delivery. Average cycle time tells how long (in calendar time) it takes to complete a typical task. The faster your average cycle time, the quicker you can introduce new features to your end users.
Tracking cycle time is easy - you only need to record when a work was started on a task, and when it was completed. When using a physical Kanban board, one of the team members (usually the Scrum Master) takes a habit of writing down the date and time when a card was moved to "Doing" column (or whatever name you use for the column that holds work in progress). Once the card is moved to "Done", it's completion time is recorded. Cycle time is the difference of those two dates in calendar time. Most electronic tools record this information automatically, and provide it either through reports or via an API.
Identify the bottlenecks in your workflow
How do you know if your workflow is efficient or not? You've got a sense of what your velocity is and you're managing your cycle times. That's great, but you can do more than that. To really understand what causes delays, you need to dig a little deeper and quantify each individual step in your workflow to find the bottlenecks.
Below is a chart that shows you how long tasks stay in each workflow step before they're completed (click to enlarge).
One thing this chart tells us is that tasks stay 10 hours on average in the review step. Could that step be made faster somehow? Do people responsible for review get immediately notified when a task is ready for review? Should you switch that person or add another person to speed things up?
Taking your process through the loop can reveal insights that help you to improve and streamline your workflow. For example, you might find out that a certain step takes the majority of the time on a task’s journey to completion. Perhaps the Product Owner is not devoting enough time for the project and, as consequence, has become a bottleneck without even knowing it? The more transparent your process is, the easier it is to spot these kinds of anomalies and actively deal with them.
These are valuable insights that allow you to take immediate action. And by looking at the trends in retrospect you see whether your actions improved the process or not.
A good workflow guides your team to work so that the least amount of time and the fewest resources are used to accomplish a task, while not compromising quality.
Metrics can help you too. They give quantitative insight into the team's performance and provide measurable goals for the team. While they are important, don't get obsessed. There are many ways to create charts and diagrams, but if the charts don’t generate insights and help you take action, then they have no use. Always pick the metrics and visualisations that are the most relevant for your specific goals.
Thanks for reading this far. Now think about the software process you're using. Is it helping you to get predictable results? Is predictability even important in your work? Let us know in the comments.