Recently, there was an interesting problem posed on a project management discussion board. The questioner asked –
“I have recently joined a company and to one of the projects that I’m engaged we have this Scrum team that has a mixed backlog (USs and Bugs). This team’s goal is to be fixing urgent bugs and when they aren’t (doesn’t happen that often :)) they should work on the product increment.
However this team doesn’t work properly and I’m willing to change this team structure (believing that this mixed attributions aren’t helping the team’s performance + aren’t matching the Scrum iterations), making the team work exclusively on bug fixing, and leaving the product increment to another team (that already does that but in a higher proportion).
My question is: Am I missing something that could make this team to work better and to keep this structure of application support + product increment while using Scrum?
If not, then I believe I will turn this team into an exclusive application support team and use Kanban instead.”
This is a very common situation! Software teams frequently manage products – and that means they are expected to build new features for the product as well as fix defects reported in the product. Depending on the context of the team and the product, they may have to frequently make urgent fixes to address customer issues while working on regular product enhancements as well. Frequently, especially in a Scrum environment, it can be difficult to match the cadence of doing both. This was also the situation here – and what follows is my response, which the questioner accepted as the valid answer to their situation!
Don’t blame the people – blame the system!
When someone says “this team doesn’t work properly”, I am afraid they might not have identified the exact source of the problem. Is it because the team members have problems multitasking between user stories and defects? Is it because their manager isn’t setting the right priority frequently enough? Are there explicit policies defined on how they shall select the work they do on a day-to-day basis? Do they understand the impact of not servicing enough value demand (user stories or new features) while spending all their time on failure demand (defects)?
Another aspect is – why are there so many defects in the first place? What engineering practices and automation need to be put in place to reduce the overall number of bugs and improve code quality? If you are not doing test-driven development and insisting on automation of all test cases, including all defects found, perhaps that is something you need to implement that first.
These are some high-level issues that need to be addressed in order for the team to “work properly”.
At Digité, over the last 15 years, we have tried multiple approaches to keep teams motivated, take ownership of their products and deliver on a consistently predictable basis – both from a schedule and quality perspective. Our belief is that it is not only not fair to make a team work only on defects while another team gets to work on all the new, cool stuff, it is also bad management/ engineering practice. A team needs to own the product (or some part of it depending on overall size) and work on it fully – both new features and defects. This gives them full ownership of the product – and they swim or sink with it. It gives them much better knowledge of the code to understand why and where defects are occurring and what might be causing them. And managed well, it makes them take far greater pride in their work and workmanship.
Not Scrum OR Kanban. Scrum and Kanban!
Instead of trying to decide “Kanban or Scrum?”, I would, in fact, recommend that you apply Kanban on top of your current Scrum practices. That is the fundamental definition of Kanban. It is not a replacement for Scrum, rather it is a way to improve almost any process you may be using. In the case of Scrum, many folks call the resulting mix Scrumban. Apply it to your current processes to identify bottlenecks and problems – and resolve those problems.
Just to share our approach, we have a somewhat similar situation as yours. We have 3 different products, and we have product teams that own each and do all the work – new features and defect-fixes – for their products. We are not a Scrum shop, but we have a reasonably well-defined time-bucket of 4-5 weeks in which we make new releases. We use our own product to manage our roadmap and dev work. The Roadmap is managed in an ‘upstream’ Kanban board, where we do our themes –> epics –> user story breakdown and then transfer the user stories to the “downstream” Dev board. All defects either reported by Support/ Customers OR found internally during code reviews, automation runs or manual validation are directly logged in the Ready column of the Dev board. The diagram below hopefully gives you a full picture.
As team members finish what they are currently working on (Kanban discourages multitasking), they pick up new work from the Ready queue based on the priority that is discussed in the Daily Standup every day. Of course, critical or high priority defects get priority over everything else. However, we try and make sure there is always a good mix of new features getting worked on as well.
We try to balance between a predictable release schedule and overall batch-size to keep things manageable. All new features and bug-fixes are deployed on an internal staging server continually – and that is our ‘internal production server’ where we run all our other functions including support and marketing etc. – which is a great way to identify any bugs that might slip thru (almost zero) and any usability issues. And like I said, we deploy a SaaS release every 4-5 weeks with all work completed fully in that time.
I would recommend you try this out to analyze your overall situation and use Kanban effectively to discover all your process bottlenecks for a gradual overall improvement in your operation. It would be great for your team morale and productivity. It might mean doing the following –
- Studying the overall pattern of demand on your team and deciding whether you work with one Dev board – or you also use an upstream board for dealing with the incoming work better with your stakeholders.
- Defining a workflow that reflects the way your team works and mapping all the steps in the value stream, so you can fully study which of these might be bottlenecks, and why your team is spending so much time on defects. Kanban’s Flow Efficiency metric highlight just how much wait times are built in all our workflows – whether between handoffs or waiting for external input or other such issues!
- Defining WIP Limits in your Ready queue for different type of work (user stories vs. defects) so that certain capacity is always dedicated to new features.
- Look at your dev processes and automation options to reduce overall defect levels.
These are just starting points – you, of course, have a much more detailed picture of your situation! As the team starts to analyze its process on a regular basis, different solutions will emerge that you will need to try out.
—
If you are running an Application support team and have faced similar situations, I would love to hear what kind of solutions have you tried and which ones worked!
Mahesh Singh
Co-founder, Accredited Kanban Trainer/ Coach
My answer was originally posted in response to a question here –
https://pm.stackexchange.com/questions/23245/scrum-for-kind-of-application-support-team/23260#23260