Using kanban: A fine line between formalization and bureaucracy

Posted 8 months, 2 weeks ago at 6:52 pm. 0 comments

Using a kanban board for organizing tasks in a project and creating a process by which tasks go from start to finish has been gaining in popularity. With every process or idea, something can go from effective and useful to restrictive and annoying pretty easily. I hope that this doesn’t happen with kanban because the fundamental ideas underlying it have been shown to increase performance (and motivation). However, with any idea, there are times when something can be taken to extremes and people lose sight of what was useful about it to begin with. Kanban can create a workflow process where one did not exist before or improve and existing workflow by improving the cadence of work, the visibility and understanding of the project, and/or the collaboration among those working together. Kanban has the potential to do great things for project management, but there is a fine line between formalization and bureaucracy.

Applying formalization to setting up your kanban board should be relatively simple. The kanban board should build off of the understandings of the employees. This means that going to a kanban board should start off with a few simple changes before trying to implement a serious organizational change. Also, your board whether online or manual should work with employees and not against them. Other than the absolutely necessary restrictions such as limiting work in progress, there should not be a need to implement many hard restrictions and kanban software should be designed with flexibility in mind (like Zen). There should be a shared understanding of how the process works within the employees, but the software should not force unnecessary restrictions. For example, if a team wants to restrict certain things (such limiting one card of a particular color in a stage of the value stream), the software should not enforce that restriction. Departments or other teams may not want the same restriction. By forcing this restriction it is coercive rather than enabling because it works against the wishes of a certain group. Not only that but the understanding of any restrictions should come from a shared mental model within a team and not from the software. By creating too many restrictions in the software it gives the impression to employees that they can’t figure out how to create an effective process on their own. I think it is pretty clear that this would undermine the motivational potential of using kanban for project management.

There has been quite a lot of work on formalization and bureaucracy in organizational theory. Most people think about formalization in the classic Weber (1922) sense of bureaucracy (who published a lot of work of effective organizational structures), but there is a difference between the two in that formalization is simply having assigned roles and guidelines that people follow, while bureaucracy is taking the role and rules to an extreme by setting up roles that are strictly assigned and a hierarchy of authority where information flows from the top of the structure to the bottom. Weber suggested that a bureaucratic structure would lead to greater speed and efficiency and less role ambiguity. While this is probably true in some cases, it tends to go hand-in-hand with the typical command-and-control mentality that simply does not work for creative and thought-based work. Though a company can and should provide a strong vision for their product or service, managers, the organizational structure, and the process set up for the completion of work should not be giving orders and restricting the way that people work.

Instead, companies should focus on a less strict form of formalization, called enabling formalization. This type of formalization provides role clarity, allows for learning, and creates an environment conducive to quick decision-making (Perrow, 1986). If the structure is enabling, it allows people to interact with the environment, which is important because it mobilizes the intelligence of the employees, rather than trying to replace it (Adler & Borys, 1996). The point is that your formalization structure should not replace the thoughts of your employees. This means that the structure of an organization should be set up to use best practices that are drawn from the thoughts and experiences of the employees (Nelson & Winter, 1982). In order for the formalization of the organization to be considered enabling, it needs to facilitate the procedures necessary for business and not create a strict structure in and of itself that works against employees.