Multiple workflows on Kanban

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.

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?

@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.

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.

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 

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.

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

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?

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.

Thoughts?