Every board should be designed based on the context that they are serving within. A board is effectively a reflection of what is going on for that team / group. Given that each context has a specific purpose, types of work, policies etc and that the board is supposed to reflect the reality, then it makes no sense that you should have a standard design. In order to be an accurate reflection of what’s going on, it really needs to be specific to your context to give you an accurate understanding. Often people model knowledge work Kanban on manufacturing Kanban (where standardisation is more prevalent / fit for purpose) and this understanding doesn’t necessarily transpose into knowledge work in the same way.
Why Standard boards are detrimental
It doesn’t reflect reality
Different contexts of knowledge work have different workflows, work item types, classes of service, policies and more. If you were asked to reflect the work of a software fix with a marketing campaign – these work items are completely different for practically all of those things – thus if you were to use a “Standard” workflow you wouldn’t necessarily be modelling the reality of your context – you would be shoe horning the reality to suit the shared model.
Different contexts have different workflows, work item types, classes of service, policies etc. These contexts each have their own reality that we are trying to model and reflect with the board. By using a “Standard” board, you’re robbing yourself of the reflection capability of the board – making it a misleading feedback loop. For example, you wouldn’t use the same board to model the work of a software fix as you would a marketing campaign – these are completely different types of work. Even if you have multiple teams building software, you wouldn’t model them in the same way. Each team might represent a different type of work – for example an API team might be different from a mobile device team. They would have different mechanisms for discovering work, managing dependencies and deploying software. If you don’t get an accurate reflection of what’s going on, it’s going to make the work quite hard to manage.
It keeps maturity low
The simplest common workflow would often be “To do”, “In Progress” and “Done” – this would often be the common denominator in different contexts. This is basically the lowest for of maturity for a workflow. However, this is too simple to reflect what’s actually going on – ideally the process should evolve and mature as the group’s understanding of the domain improves. Thus, locking into a “Standard” way of doing things will ensure that a group’s maturity is held low for as long as they maintain the “Standard”.
It hides problems
“Standard” boards tend not to show up particular queues, bottlenecks and other issues that you would see with a board that is unique to its context. Oftentimes, these items go hidden which means that a team might be suffering from overburden or managers are having difficultly to reliably and repeatedly deliver a service. It prevents the action and emergent leadership that we see with boards that are customised to the context (further keeping maturity lower).
It prevents experimentation
If you want to improve, at some point you’ll need to do something different. Having a standard board will prevent experimentation and improvement because people will think that they can’t change the standard. Being able to conduct safe to fail experiments is part of how we improve in a safe way – Standard boards prevent such improvements. In order for a change to actually be made to a “Standard” board it will have to be suitable for all contexts, thus preventing many improvements for a particular context or purpose.
What causes “Standard” boards
Not understanding Knowledge work
A lack of understanding of the nature of knowledge work and how to manage it is often a central part of what causes “Standard” boards. Many people don’t “see” the services being rendered and the nuances involved in each context. Indeed many people don’t know how to distinguish between work item types and classes of service, thus are missing some of the basics of how to understand and design services. If you’re looking to get a basic understanding of knowledge work and how to create Kanban Systems, come along to a Kanban System Design course.
Lack of Policies
I believe that when we see a lack of policy support in tooling, this often leads to calls for standardisation. That is, without the ability to simply define the policies for a service / team, leaders often look for a “standard” process that everyone can follow such that they can have a single definition that they apply everywhere. However, if we were able to quite simply put the policies in place with the board, all parties will be able to understand “how the work works”. Jira is a very popular tool and is amongst tools that don’t support this out of the box, but check out my post on Jira Kanban Board Hacks to get around it.
Misunderstanding metrics / calls for “Standard” Metrics
Oftentimes, there may be a call to have some “standard” metrics and a way to capture them for all teams / groups. Given that the tooling doesn’t easily support basic metrics (such as Lead Time) and how to capture it is difficult, people often resort to a “Standard” board so that they know where the commit point and delivery point is for all teams. However, if there were a simple way for teams to configure where their lead times start and end in their flow it would make the capturing of those metrics simple and not require a “Standard” board design. The key is the metric, so long as that can be derived then it should put unnecessary constraints on how teams / groups work.
Other Tooling Limitations
In year’s gone by, tools like Jira, which are centrally administered, have often had policies to prevent the proliferation of greater customisation of workflows / how they are managed. Although this has somewhat improved over the years, oftentimes these legacies are still present. Given that these tools have a centralised design rather than a distributed design, it often leads to calls for “Standard” workflows so as not to complicate the configuration of the tool. However, again, you’re constraining the way you do business to the way your tool behaves – perhaps you might want to consider an option that supports the flexibility of your business, rather than one that unnecessarily constrains it.
Conclusion
Having a “Standard” board design makes no sense in knowledge work. It’s puts an unnecessary constraint on your organisation that will hold back growing deeper maturity with your teams & services. This is not an enabling constraint, but rather it is disabling your ability to improve and compete in the market. You should strive to design your Kanban systems from first principles, using STATIK (Systems Thinking Approach to Introducing Kanban) to guide you in the system’s design and create a board to reflect that design, context and purpose.