What is the ongoing value of the Kanban board to the developers as opposed to management

Question

I want to understand what others believe is the ongoing value of a Kanban board to the development team

I got into an argument recently at my small company because

A) My dev team isn't properly updating the Kanban board

B) I said that the Kanban board provides little value to the actual developers (as a partial explanation to why A began to happen).

I can solve A no problem. However I am not sure about B. I really don't believe the board provides any direct value to my devs at this point - and I don't believe I have read any literature explaining what value the developers should derive from the board other than being able to control the incoming tasks, which is dealt with at stage 1.

The CEO came back at me saying that it should provide a lot of value to them, tracking their work, knowing what phase it is in, ensuring that all phases are completed properly etc. But these are all of value to the manager - Not the developer.

We have a very simple digital board which provided a lot of value initially because it got everyone into the habit of doing all the phases I wanted them to do before releasing something - but now they know it and don't need the reminders. And because they are only ever working on 1 - maybe 2 things at a time, keeping track is no problem for them. As far as my devs are concerned, they just want to know what is the task at hand, and then they will do it.

Answer 1

Good question - well phrased.

Best answer is "Never be the senior guy with a secret".

Development is difficult to schedule. Last week I told my manager that the new tool enables me to solve very complex tasks in 5 minutes, but sometimes very simple tasks take a day or more. That experience is fairly common to most of the development tasks I've managed. The developer, the PM and the manager should all understand that all development tasks must be estimated with a confidence interval. Sometimes the dev has tools or other infrastructure that doubles or triples the estimated time of the task. That is just reality.

But having done dev myself, there are tasks where the language or the environment are missing critical tools and I have to develop the tool before I can develop the deliverable. Usually that is OK and I'm still within the estimate. But sometimes when I step off that precipice into the unknown I discover that the limits of the gap are difficult - that I have to develop tools to test the tools that compensate for the missing features. And I get nested deeply enough in there that I lose perspective on the estimated time of delivery - I'm working on the product, doing what I should, building towards the deliverable, but the time estimate is now completely out of the envelope.

That's why the devs want to update the board. Because they want to develop code; they don't want to adjust delivery dates, they don't want to negotiate with stakeholders, they don't want to discuss crashing the schedule or the dozen other things. The kanban board is the interface /API to the development process. Devs should be able to concentrate on the elegance of their code - on their professional skills. Managers should be able to observe that coding and manage cost/quality/schedule/stakeholders/resources/delivery.

If you want to develop, then you've got to share state information with management and permit management to do the things that are not coding. (Coding without regard to delivery is called "hobby" and it doesn't pay reliably).

If you don't update the kanban board, then you're preventing me from doing my job (supporting the dev). If you don't update the kanban board and you exceed your estimate, then you're the senior guy with a secret and you deserve all the punishment you get. If you don't update the kanban board then you're forcing management to do exception handling - which consists of hanging over your cubicle wall bothering you with requests for TPS & estimates, and stakeholder status messages. If you do update the kanban board, then the manager can do all those things, leaving you free to do the work that is satisfying.

An updated Kanban board is valuable to the dev because informed management is valuable to devs. If management is not informed, management must interrupt flow to get answers. Having said that, I have to acknowledge the excellent and succinct summary provided by Barnaby Golden. I was working on the assumption that the company was small enough that the knowledge of handoff and complete was conveyed through tribal knowledge and didn't need a process.

Subsequently occurred to me that "As a developer, Kanban tells me whether my work is critical path, and allows me to estimate how long until I am critical path". Although Kanban isn't about "critical path", on any development effort where the work is shared, there are moments where work is tightly coupled/highly dependent, and times when work is loosely coupled (We can't finish the deliverable until we both finish, but until then we can work independently). The Kanban board is a place to register information that tells each developer how tightly coupled they are. If I were developing, I'd want to keep track of whether other people's work depended on mine (or vice versa). That is separate from the fact (described in detail above) that management needs the most status information on the most tightly coupled/critical path development efforts.

Finally I want to recognize @SirTechSpec's excellent summary which I will quote below because comments are ephemeral

Speaking as someone who didn't have this at my last job, to disastrous effect - the chief direct value of the kanban to devs is being able to point to it and say "no", phrased as "I can do that, but I'm at my limit for items in progress. Have you negotiated with the owners of those tasks to suspend work, or shall I add it to the backlog?"

Kanban is about throttling effort. Using the Kanban board should halt the practice of piling work on until the developers protest.

Answer 2

A Kanban board helps developers synchronise their work.

• Sue glanced up at the Kanban board to see if there were any new items waiting for her to code.
• Mark had noticed that the review stage on the Kanban board had hit the work in progress limit and so decided his next task should be to review something.
• Karen had just heard that the deadline had changed and so pushed one ticket right to the top of the Kanban board. The developers noticed and started a conversation about what to do next.

Of course the less items the team has to deal with, the less significant synchronisation becomes. I can imagine a situation where the effort required to update the board is not offset by the value gained. However, that is pretty rare.

It is also worth noting that management being able to track work on the Kanban board is very important to developers as it stops them being constantly bothered for updates.

Finally, I would say that a developer, like any other team member, should be looking at what is valuable to the organisation and not just what is valuable to them personally. The attitude that they are only there to do one specific task is a silo mentality that often reduces the effectiveness of organisations.

Answer 3

As a developer, a kanban board shows me two things of interest:

1. What work am I and my team members currently working on
2. What work is ready to be picked up when I complete my current task

Besides that, it is nice to have a place to leave the work card to announce it has been completed.

In a situation where there are no hand-overs (or significant waiting times) between starting work on a work-item and completing it, a board with three columns (todo/backlog - in progress - done) is completely sufficient for the developers.

If your process does include hand-overs (e.g. from developer to tester) or waiting times (e.g. waiting for parts to arrive), then the board might have additional columns so everyone (including the developers) can see why there is no apparent progress on a ticket (still waiting for that supplier), without having to ask the person that last worked on it, or what work is waiting to be handed over.

If your board contains multiple columns that appear to be of no use for the developers and where they fail to consistently update the board status, then I would advise to have a meeting with the developers and the other stakeholders of the board and discuss what critical information would get lost by merging the columns (and is already being lost due to the lack of updates). On the one hand, this can reduce what is felt as reporting overhead by the developers and on the other hand it can create awareness why correctly updating the remaining columns is of value to all involved.

Answer 4

We used Kanban at my last workplace, with only 3-5 devs (myself included), 0-2 testers and one local manager. We saw several tangible benefits:

• Knowledge gets spread around, because we're encouraged to work on the next thing on the list rather than what we specialize in. Since everyone had a reasonable level of understanding of basically the entire system because of pair programming this worked fine, but in actively siloed or politically charged work environments this may not work.
• Work got finished rather than just first-round-of-code-complete. Code which is not in front of customers is not finished yet, and Kanban's "rightmost first" rule really encourages people to get things through the pipe. This does require discipline and/or follow-up, though.
• No interaction needed to establish the next work item. Pick one up and off you go.

We also did regular reviews of our processes, including Kanban, which is really useful to figure out what the benefits and possible improvements are. If someone brings up getting rid of Kanban then it can be countered in the open that management needs some way of getting an overview, and that the replacement may well be more meetings or even some over-complicated ticketing system. Since nobody wants more meetings and all ticketing systems are over-complicated once you try to actually track progress, Kanban gets stuff done with minimal fuss.

Answer 5

"And because they are only ever working on 1 - maybe 2 things at a time, keeping track is no problem for them."

Well, yes, if every person on a team is only ever working on 1 thing at a time, then Kanban probably isn't bringing much value to anyone.

I don't feel like that should be controversial, but I may be mistaken.

Answer 6

Direct feedback

The CEO came back at me saying that it should provide a lot of value to them, [..]. But these are all of value to the manager - Not the developer.

"It should help" is not an argument. It is a suggestion/command under the guise of what seems to be informative advice. But that doesn't prove that the CEO is wrong, it only suggests that he's not really addressing the concrete reasons for needing to use the board or addressing why the developers aren't using it.

Nonetheless, I can't exclude that this isn't just a case of developers refusing to do the administration that comes with managing their tasks.

I really don't believe the board provides any direct value to my devs at this point - and I don't believe I have read any literature explaining what value the developers should derive from the board other than being able to control the incoming tasks, which is dealt with at stage 1.

Your description is a bit vague for me to judge whether the above principle applies to your case, or whether you simply miss the benefit of (correctly) using kanban.

However, based on the following quotes, I do think you're glossing over the bus factor.

We have a very simple digital board which provided a lot of value initially because it got everyone into the habit of doing all the phases I wanted them to do before releasing something - but now they know it and don't need the reminders.

Bus factor: if your devs get run over by a bus tomorrow, will the newly hired devs understand the current state of the project? Nope. Because the old devs never wrote it down.

You are relying on the fact that when they leave the office, they will be back the next day to resume their work, and you assume they will remember where they left off.

And because they are only ever working on 1 - maybe 2 things at a time, keeping track is no problem for them. As far as my devs are concerned, they just want to know what is the task at hand, and then they will do it.

The same bus factor argument applies. What happens if the devs are sidetracked for some unexpected reason, and can only come back to their tasks after a significant absence? Will they remember everything? What if some of the devs don't come back and others have to pick up the work they left?

The hallmark for proper documentation (or in this case development tracking) is that you should be able to minimize the time loss from substituting everyone working on the project by someone with equal skill but lacking contextual knowledge of the project.
That's never truly achievable. Projects always rely on some form of contextual knowledge (even if only to understand the goal of the application). But you should minimize it to the best of your abilities, because you never know what might happen. Every person working on this project could drop dead or become otherwise unavailable at any time, and you need to prepare for that eventuality.

---

A reasonable limit

The thing is there there is wiggle room here. When we're talking about tasks that refer to small (<2h) bugs, I agree that the admin becomes a disproportionate hurdle, and the bus factor is minimized since at most you lose 2 hours of work.

But when your tasks include big feature sets, or tasks that take multiple days (or even weeks), the related administrative work is comparatively small and much more relevant. Without proper tracking, if the dev lands under a bus, you're going to lose all the work they did and may end up having to develop the feature from scratch (because it may take longer to figure out what they were doing as opposed to doing it from scratch).

---

A possibly bad Kanban board

However, it's still possible that the kanban board isn't actually tailored to the developer's needs, but only to those of management. Kanban boards can be useful, but that doesn't mean that every Kanban board is sufficiently useful to everyone involved.

A real world example with Jira's kanban-like board for sprints, used in my company:

My company has defined three swimlanes: to do, in progress, resolved (the fourth, closed is not visible to developers). But there is a complication: the "in progress" time is being tracked as billable hours to the customer.

The problem this creates is that we sometimes develop something, and it either gets put on hold or it awaits testing by a QA tester.

• When we put the ticket as resolved, it auto-closes at the end of the sprint. PMs are also liable to communicate the resolution to the customer even though the problem is not provably solved yet. But even if you ignore the auto-close feature, "resolved" does not accurately reflect the state of a ticket that "should be tested".
• When we leave the ticket as in progress, time keeps ticking and billable hours become incorrect.

The only other option is to put it back as a todo item. But at the end of the sprint, management then comes and asks the developers (not the testers) why they didn't pick up this ticket. And when the developers respond, management explains that they don't care about the internal workings of the desk (testing is considered part of development), they just use this to keep track of the state of tasks so they can update the customer.

The problem here is that the board does not allow for accurately reflecting the state of things, which means that it loses all purpose for developers, who are now forced to remember the real state of things while also having to update a board that is (to them) incorrect.

This is just an example, and a very specific one. It could easily be resolved by adding additional swimlanes and ways to calculate billable hours.
But it highlights an often recurring problem when developers reject using a system that management wants them to use: its intended usage benefits management, but not the developers.

Answer 7

It makes blocks clear and visible. It also makes stand up meetings easy to have via walking the board, going through each item on the board instead of asking each person about their projects.

If the devs are saying it's of no use, that probably means the board has too much stuff on it. Updating the board should be happening during stand up meetings too. No one should be expected to update the board on their own time where no one can see it happening.

Answer 8

A Kanban board, and in general, a Kanban system, properly implemented with WIP Limits and Pull mechanism to let a developer pull new work when they are done with whatever they had on their plate, provide them with the following direct benefits -

1. It helps reduce overburdening. WIP Limits encourage the team to reduce multitasking, by helping them focus on finishing things in hand first, before taking up new stuff. While your team may not have had the problem, probably BECAUSE they have a Kanban board, most teams are faced with huge backlogs or demand from customers/ management. Kanban boards with WIP limits help reduce multitasking and overburdening. This has untold benefits in terms of improving their efficiency, helping their brains become sharper (a multi-tasking brain, in fact, becomes stupider, as research in recent times has shown!), delivering more with less and achieving better work-life balance! One of our customers actually said that implementing Kanban in a DevOps environment helped their teams by freeing them up from mundane tasks and helping them focus on more creative aspects of their jobs.

2. It provides them reliable, real-life past performance data on different types of work they perform - and this helps them become more predictable. Kanban boards should provide rich insights into lead time to finish work in general, and over any reasonable period of time, provide a great historic record of what they can accomplish. It thus helps them become more predictable - for their own ability to give more reliable forecasts of how long it might take them to do a piece of work, and for the team/ system overall to make commitments they can keep to their customer. They can easily use their throughput chart and their lead time distribution charts to get an idea of how much they can deliver in a given period of time.

3. Finally, a Kanban system properly implemented, especially with respect to upstream kanban, ensures that a developer works on the right thing at the right time. In other words, there is no ambiguity on what is the work they need to do when they have the capacity. This helps them understand the strategic alignment of their work to corporate objectives defined in higher level kanban boards.

In doing so, the Kanban system also helps the organization and the managers because, as a system, the team delivers more, better. And that helps the teams who successfully implement Kanban first!