How to best work with Kanban through multiple sub teams

Question

We want to work as smoothly with our Jira stories as possible through our sub teams Ux, Code and Test without creating huge backlogs between each sub teams. We have decided to try a Kanban board with restrictions on the work load of Status = IN PROGRESS for each sub team. First we have a backlog that's the same for the whole team. Then we have discussed the possibility to limit the flow between sub teams in such a way that the next team will pull cards when they have a slot available in their column with Status = TO DO. The goal being that the workload is similar between the teams and thus it will be a short time between requirement/Ux until we can put the story into production. We also don't want any team to over produce (think of it as we don't want a three month backlog for Code just cause it can be quicker for req/ux to put items through). One risk we see with this setup is that in the previous scenario req/ux can't produce anything since Code isn't done. The organization will have to decide if it's better to have resources "doing nothing" (ie re-allocate them temporarily to other teams) or if it's better go have a potential backlog for every sub team.

How have you worked with the Kanban board to get

a) short time from req/ux to production for all stories?

b) visulize where the issues in the chain req/ux -> code -> test are?

Vigfus Andersson · Answer

Thanks Joey!

Yeah, I think it will be crucial to find a way to break down each card of work to managable sizes to mitigate the risk of bottle necks.

Time slots with less through put due to bottle necks can, like you say, be put to good use to handle tasks related to sub team improvements like technical debt etc.

Joey_Spooner · Answer

Hi Vigfus, yes to (a) and (b).

For (a), I keep my limits low. Probably two per column for a team that needs to move fast. This is harder to handle, but works well if you need to go quickly. The challenge is to make the work really small in size so it can move quickly.

For (b), I use multiple boards. One end-to-end board for all teams and one for each team. What's great about creating an end-to-end board is that you can define a simpler view of the work (e.g., To-Do, Doing, Done) versus the code view (as it's own board) which may have columns like (analyze, dev, etc.).

In terms of doing nothing, there's always something else that could be done.

Your whole organization might benefit by making a few decisions:

* Configure a new select field called "Service Level" and have it hold at least a Standard level and Intangible. The intangible can permit work that's of lower value to the business, but might improve the team's capability; e.g., BDD for the developers or testers, advanced U/X tools that would speed up feedback loops for requirements analysis, etc.
* Configure swimlanes to support the visualization of #1. Splitting the view between the service levels. 
* Offer up bonus training (or some other reward) for people who participate/support in the removal of work that's delaying the progress of the whole team

Lastly, you're welcome to engage me via LinkedIn. I can offer you a bit more off-list.

Good luck!

-Joey