As an internal service group, Build Engineering, we support many different products with numerous agile development teams. We have a large set of requests that come through from infrastructure to releasing our products. It difficult to communicate to our ‘customers’ the priority of their issue and when their issue will be worked on. Satisfying our customers means that we needed to manage expectations, provide clear communication, and show the flow of progress from creation to completion.
How can we be successful?
Agile Methods & Agile Tools
Our customers range from IT and Development interactions, most common for a build engineer, to Support, External Developers, and Marketing. Inspired and led by my colleague Peter Leschev, our team practices Kanban to help sort the incoming barrage of customer requests. With GreenHopper’s Rapid Board we were able to replace our physical wallboards to automatically manage our Jira issues with a great Agile tool.
Keep the Issue Up to Date
Frequent communication and checkpoints are a great way to ease customer anxiety. Letting them know, even if there wasn’t any progress, about the issue’s status is important for them. In our Kanban design, when we put an issue to ‘In Progress’, this means we’re working on it now. Then keep the issue up to date, be informative on any research and findings, and ask the customer any needed information.
Triage the Issues Quickly
As a customer, when you raise an issue you want to know that someone is going to review the issue. Some customers even resort to raising their issues as a “Blocker” just to get our attention.
The act of triaging issues involves moving them from Untriaged to either Backlog, indicating to the customer that we’ve seen the issue and considered it, or to Triaged, showing that we’ve looked at it and that it’s prepared to go into our Backlog. We might even ask a few questions during this process if we really do not understand the request. We need to decide how to then prioritize or discuss on how to get the issue from Triage to our Backlog To-Do list.
Originally our team lead, Peter Leschev, handled all the triaging of the issues from an Untriaged state. From the graph below we didn’t have a lot of success with only one person always doing it. It took on average 1.9 days to move an issue out of the Untriaged state as shown on this control chart.
Consequently, we’ve set a bar where all incoming issues should never sit in the Untriaged state for over 12 hours. To achieve this, we are introducing the concept of the Disturbed, a rotating role among team members for one week stints to have one of their primary responsibilities be to triage issues out of the Untriaged state. This can enable, then, for the rest of the team to not worry or be distracted by the incoming issue traffic.
Getting Our Issues Done, Well
On a daily basis, our build engineering team uses a trimmed down view of the Rapid Board consisting of only three columns: Backlog, In Progress, and Done.
This allows the team to focus on the issues that need to flow across the board, without worrying about issues that aren’t yet on the backlog or getting frustrated by the growing pile.
The Backlog column has a WIP (Work In Progress) limit to ensure that anything that is added to this column is tackled in a reasonable amount of time. If you increase the Backlog column WIP this will increase the average time it takes for an issue to be addressed because you are trying to get more issues done with the same amount of resources.
The In Progress column also has a WIP limit to ensure we don’t context switch too much from one issue to another. By having these limits, we can commit to all our customers that once an issue gets into the Backlog, we will get it resolved in a consistent amount of time with a fair amount of confidence. How are we going with it at the moment from when we started?
This control chart shows the average time for an issue to get done after it was put into the Backlog to be 5.8 days. If we break it down to just showing Backlog and In Progress we can see that the average time spent in the Backlog was 4.5 days average time to finish work was 1.7 days.
Only Backlog Status:
Only In Progress Status:
Using the new control graph, we can quickly identify issues that took too long and reflect on areas to improve for future requests. We need to be committed to taking the oldest issue from the Backlog and moving it along across the Rapid Board. In GreenHopper, we can easily see the age of an issue in a column by the dot status on the issue’s card.
Selecting the Backlog
Selecting the Backlog – what we’ll work on next – means prioritizing work from all of our customers. In the past it was individual Build Engineers that selected their own backog to work on.
In a simple Kanban setup, there is one Product Owner who selects what issues need to be worked on ‘Next’ and fills the Backlog when that column falls under a certain limit. In the future, we want to focus on our customers selecting what we work on. With categories that can be visualized as swimlanes in the Kanban Rapid View we can efficiently let each customer, or category, then prioritize their own backlog which will then go to a build engineer tasked to that swimlane.
Challenges
We still have challenges even after using a great tool for a visual Rapid Board. One of the main struggles is how to handle blocked issues. These are issues where we are either waiting on the customer for response or we are waiting for action from another team. We’re using a Jira label of blocked to help us out and by giving these issues their own swimlane.
WIP limits are always being refined. How many issues can we handle at one time? Setting a WIP for any agile team is a challenge that needs to go through refinement.
Finally, how do we work on the larger scale, refactor and get-ahead projects while still getting our issues into the Done column. This is a cost investment for any Agile team using Kanban and we certainly have the same challenge.
The great thing, however, about Agile and using the GreenHopper Rapid Board is that we can continuously improve the way we plan our work. We don’t have to get our process set in stone and can adjust as demands from our customers change.
Update
See the second part in this series: Satisfying Our Internal Customers, Part 2, by Using Kanban and GreenHopper.