Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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:
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.
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:
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.
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:
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.
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.
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.
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.
