1

Recently we've started an experiment that everyone on the team (six devs) pull the top item off the backlog regardless of what it is. For context we maintain eight existing services that compose of frontend/backend components and we usually work on 2 new projects while fixing and added to those other services.

In practice what this would mean is dev1 could pull a bug first, then a frontend task on project 1 and then a backend task in project 2 and on and on. This constant context switching seems like it might be counter productive but I can't find any resources to back that theory up. The reasoning for this experiment is to make the devs sure that all the tickets are well scoped with enough context so any dev that hasn't worked on the project before could pick it up and work on it.

Because I can't find a lot of examples of how people manage and maintain kanban boards I'm having a hard time providing data to this discussion but it just feels inefficient. Does anyone have experience with this, is this a good/bad approach, are there any resources about this I can read?

  • Are you asking if it makes sense to share all the projects among all developers? Or about how to build a board around it? These seem to be different questions. – Stanislav Bashkyrtsev Apr 25 at 13:34
2

It is not quite clear whether you have a multi-tasking or context switching challenge or not. Since, as a team, you are supporting 8 different streams of work (6 services and 2 projects), you are already used to (the idea of) doing it. So, mentally, each of your team members is prepared to work in that fashion.

There's been a lot of research that shows that context switching definitely creates a problem. See this article by Ruth Mantell - Multitasking: More is Less (https://www.wsj.com/articles/SB10001424052702303544604576436572369558128?shareToken=stfcb09c464775476b8fff5b8b5aa0962d) or this one - Multitasking: Switching Costs (https://www.apa.org/research/action/multitask). However, what exactly is multitasking and if you are really context switching is open to question based on your specific situation.

From what you have said, your team members pick a task - and implied that they complete that task before picking up the next one. I'd argue that as long as they are completing the work they have already started, and not juggle between 2 or more open tasks simultaneously, you are doing fine. You can easily "implement" this using your Kanban board with WIP limits (Work-in-progress) - one of the key principles of Kanban. To learn more about Kanban's principles of improving flow while minimizing multitasking, you can look at our Kanban guide here.

Next, let's look at your policies you've decided on for your work.

You said -

Recently we've started an experiment that everyone on the team (six devs) pull the top item off the backlog regardless of what it is.

What was the reasoning or thought process behind this? Clearly, your team has committed to supporting those 8 streams of work - and you are trying to provide equal capacity to each. If all services have the same priority, then perhaps that might work well.

However, are their different priorities for each of them? Kanban refers to this as "Class of Service". Do you think that instead of giving equal priority to each, there is some differentiation needed in order for you to meet your SLAs to your customers? If so, you might consider organizing your Kanban board differently, perhaps by class-of-service (a separate swim lane on the Kanban board for say, urgent or Expedited items) or some other way - that is a discussion your team needs to have amongst yourselves, and maybe with your customer(s).

Just to share our own example, we use 2 Kanban boards - an "upstream" Kanban board for our product roadmap/ backlog grooming, and a "downstream" one where our Dev team works on both roadmap work (similar to your projects) and also on a mix of other work that includes bug-fixes, customer implementation related work and so on. Our boards and workflows look as shown below -

enter image description here

Our Dev team's board has multiple lanes to track the different services they provide -

enter image description here

Being a product company, we have established - over years of experimenting - that a 4-6 week cadence for making product releases works well for us. We work around this cadence for prioritizing and grouping work in different streams. Our Prod Management team works to identify and prioritize themes, epics and user stories on the roadmap board to keep the Dev team fed with the right work at the right time. Overall, the process works well, and we have been able to maintain a fairly happy set of customers who give us high marks for the support and responsiveness we demonstrate to them, besides of course the product itself :)

Overall, my recommendation would be to have a discussion within your team, and with your customers/ stakeholders on -

  1. Are they finishing work in progress before taking up new ones? If yes, that's great (else, re-emphasize the "Stop Starting! Start Finishing!" mantra with them.)

  2. Do they feel confused or unproductive because of having to switch between different projects and services? If no, then great. If yes, then you've to think of how to perhaps reorganize your team into sub-teams that handle smaller groups of services that are less diverse, helping them work on similar work-items at a stretch.

  3. Are you meeting your commitments to your customers? Does everyone have a clear - and common - picture of what those commitments are? If the answer to either one of them is No, you've got to ensure you have clarity there in order to best decide how to reorganize your work policies so that your team is clear and comfortable with what work they pull next after finishing up what they were already working on.

Hopefully, our Kanban guide as also our blog will provide you with additional reading on how to manage your teams work.

2

Priorities are not the absolute decider of work order. A team will try to work on tasks in priority order, but they will also:

  • Consider who is available to do the work.
  • Think about the technical implications of task ordering.
  • Consider things like training opportunities, knowledge transfer, etc.
  • Consider the size of tasks.

A better way to think of priorities is as a guide to help the team when resolving conflicts.

For example:

I can do either Task X or Task Y, which shall I do?

Task Y is the higher priority, go with that

However, it is important that any decisions made by the team are discussed with the person who set the priorities.

A typical conversation might be:

I know you said we should make Task X the top priority, but from a technical point of view it makes more sense for us to do Task Y first. Let me explain to you why...

As usual in agile, it is the conversation that is important. Business priorities have to be carefully balanced against the effectiveness of the team and decisions should be taken in a collaborative fashion.

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.