6

Is it OK in Kanban that a developer may be involved in another developer's work (helps, consults) for a significant amount of time (a half day)?

The work item of the first developer is staying in "In Progress" column, but he isn't really workin on it.

We don't log work in Jira. This is a general question about Kanban.

  • "The work item of the first developer is staying in "In Progress" column, but he isn't really workin on it." I think that's the real problem here. Do you have a column for tasks that are On Hold? – Mast Dec 22 '19 at 14:06
  • @Mast No. Should I? – Chris Brettini Dec 22 '19 at 15:16
  • Nobody is forcing anyone anything, but for some groups it helps to have such a column to keep track of tasks which got stuck. If a task is stuck for too long, depending on the priority given to it, it may need additional resources (developertime or otherwise) to prevent it from becoming blocking. Especially useful with sprints and sprint-like approaches, but also for teams working on multiple project at a time. – Mast Dec 22 '19 at 16:02
17

TL;DR

Your question strongly implies management metrics tied to individual utilization rather than flow or cycle time. The 100% utilization fallacy is antithetical to Kanban, and to agile systems in general.

Furthermore, Kanban systems aren't intrinsically concerned with how much time individuals allocate to a given task. Instead, they focus on the cycle time of tasks and processes to increase flow.

Below, I address the Kanban, agile, and cultural perspectives that underlie your question. These perspectives also provide some guidance for treating Kanban as an organizational process that can address and improve these three dimensions, and thereby improve the overall effectiveness of delivery within the framework.

The Kanban Perspective

Is it OK in Kanban that a developer may be involved in another developer's work (helps, consults) for a significant amount of time (a half day)?

Kanban is not prescriptive about the structure of working agreements. So, the short answer is that it's okay to do this if it:

  1. fits within the team's working agreement, and
  2. doing so doesn't violate any work-in-progress limits.

It may even be advantageous to do so, because having more resources working on a given work item reduces work-in-progress (WIP) for the team, e.g. you don't have somebody starting yet another task before something else is completed. It can also reduce cycle time for collaborative tasks, and lead time to dependent tasks.

In short, Kanban allows you to work any way you like within the framework's requirements to visualize work and limit work-in-progress.

The Agile Perspective

Agile frameworks value collaboration. Parceling out work in single-task units and assigning them to individuals is generally an agile anti-pattern for a host of reasons. While Kanban grew out of the Toyota Production Method, and assembly-line work is often task-based, the overall goal is continuous flow of work rather than individual utilization.

Most successful Scrum and Kanban teams will collaborate heavily on tasks, self-organize the workflow to optimize flow and limit work-in-progress, and generally swarm as a team over WIP that is not actively flowing. This is exactly what you want.

If Developer X is building a widget (call it Task N) that Developer Y needs to start some other task (call it Task M), Kanban generally requires that dependent task N be completed before M is started. Therefore, it's in everyone's best interest that Developer Y help Developer X so that the output of N can be pulled into M.

There are always edge cases and caveats. For example, if Developer Y is primarily allocated to a work stream that has free WIP slots and has other work to do that is not dependent on Task N, then that should take priority. Otherwise, Developer Y would have to choose between:

  • Helping out on Task N to improve flow.
  • Waiting idly for Task N to be completed.
  • Doing busy-work to create the illusion of productivity.

The whole point of agile systems like Kanban (and Lean in general) is to eliminate waste. Reducing the cycle time of WIP through the system eliminates waste and bottlenecks, and is therefore usually the right thing to do.

The Cultural Perspective

Your core question strongly implies that everyone on the "team" (and I'm using that word loosely) should be working in a dedicated silo, tossing completed work items over the wall to one another. This is generally symptomatic of one or more of the following:

  1. Management that measures resource utilization rather than outcomes,
  2. Command-and-control management that doesn't benefit from the agile principles of empirical control processes.
  3. A cultural bias against collaboration and collective ownership of the work product.
  4. A management team that cares more about how things are done, rather than focusing on whether things are done.
  5. Conflating time on task with effort or efficiency.

Adopting Kanban without clear working agreements within the team, and between the team and the rest of the organization, is a common source for these cultural anti-patterns. The question really shouldn't be whether Kanban allows people to collaborate, because it does. A better question is "Why doesn't the organization value collaboration and shared responsibility?" Until you haul those underlying assumptions out into the light, examine them, and adapt them into a more effective working agreement, you aren't really doing Kanban properly as a continuous-improvement process.

| improve this answer | |
4

This depends quite a bit on the team norms and standards, but often the work is taken on by the team and not an individual. Several people may be involved in doing the work, depending on what the work is and the current skills and experiences of the people involved. For example, two or more people may pair up or mob on one piece of work to share knowledge and teach each other - on some teams, this is common practice for all pieces of work. In other cases, someone may simply be involved in reviewing the work at various points in process to spread awareness and understanding.

Without fully understanding what your teams norms are and how your workflow is defined, it's difficult to give a definitive answer. Nothing in Kanban (or any other methodology that I'm aware of or have worked in) would prohibit the situation that you describe.

| improve this answer | |
0
  1. Is it OK in Kanban that a developer may be involved in another developer's work (helps, consults) for a significant amount of time (a half day)?

OK: He is allocated 1 FTE to a project and he is involved in another developer's work within the same project.

Not OK: He is allocated 1 FTE to a project and he is involved in another developer's work NOT within the same project.

  1. The work item of the first developer is staying in "In Progress" column, but he isn't really workin on it.

It is better to use a dedicated subtask in a second work item so that board will show real situation.

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