1

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 to 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 a exclusive application support team and use Kanban instead.

  • If you have 2 questions, they should be posted as 2 Questions. I'm 90% sure the second one should already exist, though - its answer is generally "yes". – Sarov Jan 9 '18 at 17:57
  • Scrum is for scope-driven work; Kanban is (generally) for demand-queued work. Urgent bugs aren't planned work; they're demand-driven, so you may need to revisit your utilization-focused strategy. – Todd A. Jacobs Jan 9 '18 at 17:58
  • @Sarov you're right, I've just edited it to keep only the first question. The second it was basically me reassuring what I've read in here already :) Thank you – Leonardo Pires Jan 9 '18 at 18:05
2

When you say "this team doesn't work properly", I am afraid you 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.

I am a co-founder of a software company - and 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.

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.

enter image description here

As team members finish what they are currently working on (Kanban discourages multitasking), they pick up new work from the Ready queue based on 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 -

  1. 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.
  2. 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!
  3. 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.
  4. 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.

I hope this helps; all the best!

2

There are some benefits of teams working production support in addition to product development as well as benefits to separating responsibilities.

Case for a team doing both

This centers around the idea of ownership by the team. When a team is asked to address production support issues in the code it builds, it encourages a higher level of quality. In addition, theoretically, that team is the best qualified to solve the support problem quickly, which means less downtime for the customer.

Case for separation of responsibilities

By having application development work interrupted by production support, we are creating what lean would call Mura - a form of waste. This is because they need to create slack in their process to allow room for the interruptions and overhead in management and context-switching.

Personal Opinion

In most cases, I would fall on the side of better quality and faster fixes over process efficiency. The value creation in the former is usually greater than the cost savings of the later. However, you know your circumstances best.

0

If you do separate bug fixing from development then the question is: Will there always be just the right balance of work for both teams?

What happens when there are no bugs for a while? Will the team sit idol? How about if there is some really critical project work and the development team is flat out while the bug-fix team is on tickover?

My personal opinion is that you are better off sticking to the mixed backlog.

An approach I've seen used in this situation is to nominate one or two Scrum team members as being 'on point' for bug fixing in each sprint. That means that they are given lower priority and smaller development tasks to work on so that they can easily switch across to fixing a critical bug. Rotate who is in this point role (say every sprint, or every couple of sprints).

It is also worth considering how quickly you need to fix urgent bugs. If they can wait a week, why not switch to a 1-week sprint cycle? That way you can cover all the work in sprint planning.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.