“Can we restrict the Kanban board so that only BAs can move user stories into ‘Ready’?”

“Can we make sure that Testers cannot move items to ‘Ready to Deploy’ until a test is attached to the ticket?”

“Can we make sure a ticket has to be dragged into each column before it can be dragged into ‘Closed’?”

Noooooooooo; Just NO; Stop now

Don’t get me wrong I completely appreciate if you choose to disagree with me on this one, but there are so many good reasons not to implement overly restrictive permission management or rules on a Kanban board.

I work with many customers who sit on the opposite side of the fence with this, hence why I wanted to write this article for quite a while now. Let me explain why I am so strictly opposed to restricting the flow of work on the Kanban board with rules and permissions…

The problem with restricting the movement of tickets on your Kanban board

A move like this is usually sold as a quality gate… “You see if the tester agrees that it is ‘Ready to Test’ they then move it into that state…” …and I mean I get why people think that, but an argument like this usually implies a lack of automation, a lack of trust, or a lack of cross functional working. (or all three of them at the same time)

First it is quite something to expect that the people you have hired automatically want to cause harm to your organisation and will not do their due diligence, but maybe that’s just me.

The objective argument though I find is that we only need a pseudo quality gate like this if our people are not united enough as a team or if our build and release processes aren’t strong enough to reject whatever is on the Kanban board anyway.

If we do not completely automate our test, build, and release procedures, then we quickly get into a situation where a Kanban-gate (yes in the sense of it being a scandal and short for quality gate) seems like the option that is easiest to implement. In a completely automated process my testing is done by the automation as changes roll out, and changes are automatically rejected if they are not up to scratch.

Finally – on the unity point – if good engineering practices are in place then no additional quality gates are required. Engineers in a good team will reject each other’s code if it isn’t covered by tests. Engineers that care about their product will recognise quality issues and avoid them.

If you need a further point against overly complicated permissions and state management on the Kanban board, then consider the following: If you had a physical Kanban board would you restrict particular people from picking up tickets during your stand-ups and moving them as they explain why they are moving them and not others? If the answer to this is “yes” then permissions management is not going to solve the problem that you are experiencing.

Let’s deal with the problem not its symptoms

To me wanting to have strict permission and state management on a digital Kanban board is just a symptom of a wider set of problems that need to be tackled.

The following list is not exhaustive:

  • Trust Issues
    • Hire good people
    • Reward good people in your organisation well and retain them
    • Have a company vision and mission
    • Communicate your company vision and make sure every member of the organisation understands their contribution to the mission
    • Hire good managers and ensure that they make your people feel valued
    • Offer opportunities for your employees to learn, exchange, and grow

  • Lack of Automation in the Delivery Cycle
    • Automate everything
    • No seriously everything
      • Functional testing
      • Unit testing
      • Build
      • Release
      • Everything

  • Siloed Teams
    • Build teams around the deliverables of your business
    • Long term align people to a product or feature area rather than a project
    • Ensure the highest possible amount of co-location and cross-skilling in a single team to avoid handoffs
    • Instil good working practices (for software development that is code reviews, continuous testing, continuous quality, monitoring, etc.)