Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Multiple workflows on Kanban

Last post 12:26 pm August 24, 2022 by Ryan Kent
9 replies
08:59 pm August 20, 2022

Hi all, 

In my organization, for a given product, we have a team that will take care of all the new functionalities of the product and another team that will take care of the support once the product it's in production (mostly incidents, bugs, etc). Both teams use Scrum as the base framework but we are planning to incorporate Kanban practices along with scrum practices to have a better flow of the work for the support teams.

The support teams as I mentioned are primarily focused on taking care of the incidents but every now and then they also tackle some new small functionalities or improvements to the product (that do not have exactly the same workflow). I'm currently preparing for the PSK and while studying the Workflow definition, I keep asking myself if in those cases,  does the team has 2 workflows? or they could use one single workflow for their work?

Are we maybe not tackling this correctly?  Any advice from your experience on how would you proceed?


12:51 am August 21, 2022

Having two workflows does make sense to me. It seems like you will probably have different service level expectations for responding to incidents than you will for planned feature/functionality development. Those different SLEs will be reflected in not only the workflow, but also other metrics, like cycle time and how you respond to aging work items.

The interesting question will be about how you visualize the workflow and the teams that are managing both incidents and planned functionality development will manage work in progress limits. There are a few possibilities here, but it really depends on details like how much of a team's time will be spent on incidents versus planned work, how many unplanned incidents you have, and the stakeholders who would want to visualize the state of the work.

06:07 am August 21, 2022

The support teams as I mentioned are primarily focused on taking care of the incidents


Are we maybe not tackling this correctly? 

Why are support teams having to mop up after a team with a poor Definition of Done?

06:46 pm August 21, 2022

@Ian, This is the way the organization is set up currently.  Not really much we can do atm to change that structure so it's a reality we need to work with.

07:02 pm August 21, 2022

Thanks for your reply Thomas.

I totally agree, with you and with Ian.  We do not have the best setup right now and we are working towards that change, but it's something that might take a bit to accomplish. 

I had the same concerns you pointed out Thomas, about the challenge of limiting WIP. I guess this will be a good opportunity to do some experimentation and then inspect the results.

09:19 pm August 21, 2022

Why are support teams having to mop up after a team with a poor Definition of Done?

 Sadly I can't edit my previous comments to include this, but this keeps resonating in my head and you are totally right.  At least for one product that I have on mind, we have what we call a "Transformation" team that handles all the "new" features of the product and once it's in production, we have a "Support" team that handles everything related to the functionalities in production, including vulnerabilities, obsolescence, etc, instead of having 2 teams that handle everything related to the product and work in sync depending on the priorities.  Prolly i wont be able to get a large-scale change done, but at least i cant start with these two teams  =)   ... thanks 

02:37 pm August 22, 2022

If you have 2 teams working "separately", you'll have to look at the benefits for having 1 flow.  Based on your description I don't see a big benefit.  Having 2 flows does seem to make sense.

Before you settle on a solution, look for the problem you are trying to solve.  Be careful not to look at an answer before you look for the problem you are trying to reduce.  Before deciding on 2 flows versus 1 flow, you should try to figure out what you're trying to fix - and that's not trying to decide a workflow, but maybe how to get flow between teams, in the teams, or maybe even better visibility so that issues can be resolved.

Also make sure to try it and inspect/adapt the result at regular intervals.

Sorry to be so obtuse, but I think you are looking at choosing between two solutions without spending enough though on what's the root problem.  As always I could be wrong - just ask my kids.

06:56 pm August 22, 2022

Sorry to be so obtuse, but I think you are looking at choosing between two solutions without spending enough though on what's the root problem.  

Hi Chuck, you are totally right. There are some other issues i need to pay attention to first

09:53 pm August 22, 2022

It's perfectly normal. You have 2 types of work, and they both have a start and endpoint, but a different path in between. So, you can visualize it like that.

Aim for the smallest amount of difference, review your workflow while you visualize it.

However, if you have 2 teams, maybe they can each have one board with one workflow?

12:26 pm August 24, 2022

I am wondering about how different the actual workflow is. 

I would imagine that incidents and production bugs follow the same rigor as a  normal product change. You may need to do some coding or configuration, test it, integrate it etc (as an example). 

Makes me wonder if the differences are more like:

  • Source and arrival pattern of work
  • Who is focused on the work
  • Cadence of and approach to work (Team A Sprints and Team B using continuous flow?)

From a board perspective there are ways that you could manage both. Swim lanes as an example. 

Different boards could also be used if it helps with focus and transparency. 

Similar to what Chuck mentions, look at the problem closely and build solutions/options from there.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.