1

We are a small team building webapps for multiple clients in parallel.

We have not been doing full-featured Scrum, but we have "sprints" and per-project boards with the following columns:

  • To do
  • In progress
  • In review
  • Done

Such board is perfect for subtasks. A feature in development is a task which requires work from several workers: designer, backend developer and frontend developer. So each worker is assigned a personal subtask and moves the subtask across the board as they make progress.

Such board makes it easy to track the workload of each worker. But this approach is suffering from many problems that Kanban is trying to solve: push-style assignments, micromanagement, lots of unfinished work in progress piling up, useless estimations, etc.

In an attempt to embrace Kanban, we've had a meeting discussing an idea to switch to using a single Kanban board. We came up with the following columns:

  • Ready for Concept

    Concept in progress

  • Ready for Design

    Design in progress

  • Ready for Develpment

    Development in progress

  • Ready for Review

    Review in progress

  • Deploying

    On dev server

    On staging server

    On production server

After discussing this for a while, we have come to a conclusion that this board is perfect for managing client-centric tasks, i. e. each card must represent a feature. Multiple workers work on each card.

But this board falls short quite miserably for managing subtasks. This is because:

  • Feature development lifecycle is not linear, i. e. frontend and backend development development can happen in parallel or in arbitrary order. We want the board to make it visible what exactly is going on at the moment, or whom to ping in order to get their reviews and unblock merging.
  • PR reviews may require 👀 of multiple people. Naturally, I want to see on the board which PRs require my attention at the moment.
  • Deployment can happen separately for backend and frontend, at least to the dev server.
  • We have per-PR preview deployments which allow QAing pending PRs. But frontend and backend PRs are preview-deployed against develop branches of each other. If a feature requires both frontend and backend changes, then it can only be QAed when at least one PR is alerady merged (then the preview deployment of the other PR will reflect the result), or when both PRs are merged (then the dev server will reflect the result).

From a client's perspective, all these details seem to be "implementation details" of the "Development in progress column". If we omit these details from the Kanban board, then the board becomes perfectly consistent and efficient at managing feature cards on general scale, i. e. without going into detail.

The problem is that we want the detail! We are going to use the Kanban board inside the team are not considering to expose the board to our clients, at least so far. Thus, we do want those "implementation details of development in progresss" to be visible on the board. We want to see the subtask cards! But at the same time, we want to embrace all the main principles of Kanban: visibility, pull-style assignments, no micromanagement, WIP limits, focus on horizontal swimlane speed at the cost of not being 100% busy all the time, etc.

So how do we do it? Use two boards in parallel? Create a 2D Kanban board? Embed one board into another? Abandon all hope?


Homework:

3
  • 1
    You say "this approach is suffering from many problems that Kanban is trying to solve: push-style assignments, micromanagement, lots of unfinished work in progress piling up, useless estimations, etc." These are behaviors that impact flow and productivity. You are suggesting a new work flow and new boards, and re-organizing stuff, but are you doing something about those behaviors? One other thing: you are doing a full replacement it seems. Have you first tried smaller, incremental changes to address the issues you have with your current approach before doing a big bang replacement? – Bogdan May 13 at 10:07
  • @Bogdan, "you are doing a full replacement it seems" — no, we are only considering it. "Have you first tried smaller, incremental changes" — no. The first thing on our wishlist is merging per-project boards into a single company-wide board. This change alone is disruptive enough to be considered an all-in move. Doing it only for some projects gives no benefit, it's all-or-nothing. Compared to this, other changes seem minor, and I see no reason so cling to old practices. – Andrey Mikhaylov - lolmaus May 13 at 10:12
  • 1
    It seems like a fundamental problem is that a Kanban board is designed to visualize a workflow. It seems like you have multiple workflows. If you use Kanban boards, you'll need boards for each workflow. However, you don't necessarily need Kanban boards for everything - there are alternate visualizations depending on what tools you have available. – Thomas Owens May 13 at 10:21
1

Being a small team, take one project at a time

You said you want to embrace 'WIP limits' principle of Kanban among others. The reason why Kanban recommends WIP limits is to help the team focus and to minimize context switching. Instead you are flying very far in the opposite direction:

Use two boards in parallel? Create a 2D Kanban board? Embed one board into another?

Assuming that you do find a tool that supports any of these, it will be a context switching nightmare for your small team because you are:

building webapps for multiple clients in parallel

My recommendation is that you should, first and foremost, apply the 'WIP limits' to the number of projects in progress at a time. One of the key requirements for this is to train your dev team to be more cross-functional. May be getting to only one project at a time is not achievable in practice. But it is worth working in that direction.

When a dev team member has completed whatever they are working on, my guideline for them is to first check whether they can help another team member to complete their work already in progress. Only if that is not at all possible, they should bring new work to 'In Progress' status.

Similarly you should ask the dev team to see what they can do to complete the project already in progress instead of bringing more projects into the 'In Progress' pool. Every new project you add to this pool exponentially increases the context switching productivity hit.

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.