Welcome back! Here with another article today and to discuss some of the problems with isolated team level kanban and why you should aim to go as high as possible in the organization. I’ll discuss some of my experiences and go into the downsides of isolated team level kanban vs the organization level. This article isn’t here to downplay the impacts of Kanban and lean principles but show some of the downsides when you’re alone without support.
For full context, I think Kanban and Lean are great and have shaped a lot of the background of what I do today. However, we need to be transparent and talk about some of the downsides about going at it alone on the team level (I’ve been there!).
Downsides to Team Level Kanban when none of the other organization uses it or understand it
Kanban is a popular Agile methodology used to manage work in a transparent and efficient manner. The core of Kanban in software development is about visualizing your work, limiting work in progress (WIP), and maximizing efficiency or flow. It is often used to manage work in progress in a highly efficient manner, using visual aids to keep track of tasks and workflow. Implementing Kanban only at the team level, and not throughout the entire organization, can have several disadvantages. Here are a few:
- Isolated Workflow: If only one team uses Kanban and others use different methods or don’t visual work fully, there might be inconsistencies and disruptions in the overall workflow of the organization. This could lead to inefficiencies and miscommunications between teams and departments. For example, team A has what we call “hidden work” and team B uses Kanban with a lot visibility. This will more than likely lead to a significant amount of friction between the teams.
- Lack of Organizational Agility: Kanban’s agility can be limited if it is only applied at the team level. To be fully effective, agile principles need to be integrated across the organization, providing agility not only at the operational level but also at strategic and portfolio levels. For example, you as a team, want to release as frequently as possible. However, your organization is stuck with quarterly release windows that don’t take advantage of small incremental changes. You will still benefit from faster flow, decreased cycle time (at least dev done) and reducing work in progress via WIP Limits.
- Lack of Organizational Visibility: One of the main benefits of Kanban is the ability to visualize work, workflow, and blockers. If Kanban is only implemented at the team level, leaders and stakeholders won’t get a clear overview of all the work happening in the organization, which can limit strategic decision-making. For example, let’s say your team has full visibility into their board. You understand the process end to end and you’ve mapped it and know your lead time roughly. Now, you realize a team that’s following a waterfall process with gant charts and no ticket creation is really impeding you and your goal of organizational visibility. This becomes a challenge to solve at the team level and will require serious organizational change and experimentation to get right.
- Cultural Disconnect: A shift to Kanban usually involves a significant cultural change, emphasizing continuous improvement, transparency, and self-organization. If only one team makes this shift, it can lead to a cultural disconnect within the organization, causing friction and misunderstandings. For example, you want to release frequently as possible. The organization deems this too risky and forces you to release during the monthly release window. This will cause a large amount of friction in the organization without proper infrastructure and buy-in. Discussions must be had in order to bridge the gap and come together on what you’re trying to accomplish.
- Scaling Issues: Implementing Kanban at the team level might work well initially, but as an organization grows, the lack of a structured, organization-wide agile framework could make scaling more difficult. Different teams could have different practices, leading to a lack of standardization. This isn’t a bad thing for some orgs. However, some prefer a single framework. For me, it’s do what works as dora metrics and lean software delivery compliment each other very well. At a tech company I worked at, there was no standard framework in place but we measured organizational performance via dora metrics and developer satisfaction. It was one of the highest performing organizations I’ve seen. Just because there’s not standard framework in place doesn’t mean you need to give up.
- Limited Benefits: The benefits derived from implementing Kanban may not be fully realized if the whole organization isn’t aligned. While the team using Kanban might see improvements in their workflow, these benefits could be undermined by inefficiencies in other parts of the organization. Ie, you’re blocked by six month deployments and you cannot unblock yourself because “that’s how this part of the organization works”. The good news is you have plenty of data to bring up a discussion and try to get that organization blocker removed. The bad news is it’ll take time, patience and quite a few conversations depending on who is leading it.
- Dependency Management: Kanban helps in visualizing and managing dependencies. However, if only one team is using it and there are cross-team dependencies, it will be challenging to manage and optimize these dependencies.
To make the most of Kanban or any Kanban, it’s typically best to apply specific principles organization-wide while having organizational buy in + champions for the org. What I mean by this is, people who understand and buy in to the process at multiple levels and areas of the organization (not just your boss).
Conclusion
While Kanban and lean are an absolute pleasure to work with at the organizational level and at specific team levels. It always takes some courageous conversations to bring up where it comes short at the team and program level. If a lot of the organization isn’t interested or not really culturally bought in, it becomes a potentially painful experience. If you need help with lean software delivery or setting up organizational benchmarks, contact me or reach out. I’m happy to help or provide some guidance.