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.
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 -
- 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.
I hope this helps; all the best!
