2

In our org we have two groups of people working on different components on a common platform (shared API, separate front-end apps) and have grown the process to the point where tracking working across the development team, architecture and data groups are important.

In our standard workflow, we'd simply create new Azure DevOps boards for each team of people (dev team 1, dev team 2, architecture, data, etc) but I'm wondering if that's really the best path since there are dependencies and overlap between those different groups. Right now we're running in a 2 week sprint cycle but do plan to move to kanban a few months down the road and I'm considering creating one board for all teams and manage groupings of people teams using tags. This seems as if it'd provide excellent flexibility for team changes (going from 2 to 3 devs or combining) while potentially sacrificing some built-in reporting in terms of story point throughput and such.

So I wanted to ask the community: would you recommend proceeding with multiple boards for each group and have potentially multiple stories across those boards but then how do we tie those to one epic/feature for planning? Or do we go the route of all in one board which simplifies planning roadmap with epics/features but could become unwieldy?

5

Unfortunately, there is no "right" answer to this question. However, there is a good way to find out the right answer for you. Especially in Kanban, the purpose of the board is to visualize your workflow. Consider a few questions:

  • Do both teams have the same workflow?
  • Does the workflow of value delivery mix between teams?
  • Do you get better visibility into how value is created by looking at the work together or separately?

Additionally, it is common that people try to find the perfect way to set up a board and lock that down. This is not possible. Your processes will change and improve and your board will need to change with them. Don't be afraid to try something and then change it. If the questions above don't lead you to a clear answer, try both ways and see what works best. You may find that it is a mix of the two even.

| improve this answer | |
1

Your question is quite representative of the kind of the initial challenges organizations go through trying to decide how to model and organize their kanban boards.

The best way to think about this is to see what the teams do. In general, a team works on multiple types of work (new feature development through user stories, issues and defect fixes, other maintenance requests, documentation, etc.) and might support more than one "service" - multiple products or applications, customers, business functions, etc.

You have the following to consider -

  1. Each team needs to be able to visualize and manage their own work easily - so they can plan their own WIP Limits, replenishment cycles of new work, resolving bottlenecks, etc. easily. For this reason, it is better to have a dedicated kanban board for each team OR at least their own dedicated swim lanes where they can manage the different types of work they do, using different colored cards.

  2. If external customers are involved, you might have the need for confidentiality and access control. People from other teams may not access data that pertains to other customers. In such a scenario, depending on the Kanban tool you use, you might HAVE to separate such customer-driven work in separate boards, and only the team assigned to that board has access to the work in it.

  3. Dependencies across teams. This is a big factor in complex product/ application environments. Different teams might work on different components of a single product or multiple related products on a single platform or platform vs. front-end, etc. Each of these scenarios will result in dependencies between teams where at a minimum, you must be able to visualize the dependencies, and ideally, even have the kanban tool make it easy to determine if some work can be started or not, depending on the completion of work being done by another team.

In my experience, working with several organizations, even teams of 10-12 people (not very big) prefer to have their own boards with multiple swim lanes that allow visualizing the different types of work they do, with specific workflows for each lane. Here is an example -

enter image description here

It is possible to have a scenario where each team has its own board, and their work (such as user stories and defects) can be linked to higher-level epics (or grouped in a release/ sprint scope) which are managed in a higher level portfolio or program board. Here is an example of such a hierarchy - where each level of cards is on a different board -

enter image description here

It is also possible to show dependency links between cards that are on different boards, depending on the tool you use.

As Daniel said, there's no right or wrong answer. However, you need to give thought to what are the key "services" that your teams are performing. These services are business-relevant/ critical - and measuring and improving their lead time/ cycle time performance, their throughput and managing their capacity vs. the demand they face - these are all the aspects that kanban helps you with. So, ideally, your kanban boards, swim lanes within boards, the workflows and card types should reflect organizational priorities, and help you manage the performance of these services - and make their services levels more predictable and reliable.

enter image description here

This will also help them generate their own performance data in a manner that they can use to set more reliable forecasts of what they can deliver per sprint/ release or month/ quarter.

Your board organization needs to be able to support this. You have already made a start. Of course, it should be possible to make changes as you experiment with these designs. A great way for each team to analyze their work and design their boards is known as STATIK (Systems Thinking Approach to Implementing Kanban) - you can read up more about this here. Also, we provide a handy guide on things to consider while designing your Kanban board that you may find useful.

Hope this helps!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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