Traditional vs Lean Management: Why You Should Be Using Kanban

Let me get this out of the way: I love Kanban. And this isn’t for any of the usual reasons, such as because it’s a visual management tool, or because it enhances work in progress control, or even because it’s self-managed. I love Kanban because it allows me to not have project management in my product team.

I’ve been a project manager, and project management is complicated. Clients would ask me for Gantts, but I didn’t understand the milestones. I had to deal with risk management instead of customer success. And while project management needs certification, lean management needs values.

Effective use of Kanban means we don’t have project managers at Resultados Digitais. Yet this doesn’t mean we don’t believe in projects (one of the selling points of our digital marketing platform, RD Station, is that it works really well for large projects) –  but we call our projects ‘Epics’ to differentiate them from ‘projects’ in the traditional project management sense.

So what are the advantages of using Kanban?

Project vs Flow

One of the main reasons I prefer Kanban over project management is because the focus of project management is the project, whereas the focus of Kanban is the flow, the process.

One of the greatest advantages of lean management, translated into tools like Kanban, is that it focuses on building and maintaining a flow where several ‘packages’ – projects and Epics – can pass through with the same quality. The focus of improvement is always on the flow, so all the lessons learned must be applied to the process and not just to the project that is passing through it. In this way, your efforts on continuous improvement will get results every time.

There are three significant components to the flow that, to my mind at least, represent the death of the project manager.

1) Definition of Done

The Definition of Done is the goal of each phase. It is what an “internal customer” (i.e. the next phase) wants the previous phase to deliver. It is a method to design the role of each phase in your Kanban flow and, above all else, ensure the quality of the packages that pass through it. The Definition of Done is a guide for what people should aim for as the project progresses. It defines the objective of a team’s work in each phase of Kanban, without dictating how this work should be done.

At Resultados Digitais the first phase of our product’s Kanban flow is problem analysis and benchmarking. Its Definition of Done is basically the validation and drill down of a bigger problem, and a benchmarking of solutions for each minor problem previously validated.

Understanding and proving a problem is essential to building great products. In fact, the lack of proper problem understanding is one of the main reasons for product failure. So as part of an ongoing cycle, we learn during each project, and we improve the Definition of Done for each phase. This way, all the learnings gained from each package are applied to the one that follows it, ensuring the same mistake does not happen twice – another very important factor in lean management.

2) Continuous improvement of the flow (process)

Easy to understand in theory, but hard to put into practice! Attacking the process and not the package might seem counter-intuitive, but it’s essential for your product when using lean management.

Let’s say that during the launch of a new feature you discover that a huge amount of support tickets are being generated by customers who didn’t understand how to use the new feature. It probably affected the engagement of these users and it happened because of an education failure. Your support team is already helping these users and your development team is deploying an update to fix the problem. Despite this extra cost, lean management forces you to focus on finding where your flow failed (i.e. where this ‘error’ was created) and improving your process so the same mistake does not happen again with other projects (features, enhancements, etc). Where should you take action so this problem doesn’t happen again? At the Alpha phase? During your usability testing? On designing a solution?

Continuous improvement is a key factor in ensuring other projects do not fail in the same way. Apply it to your flow.

3) The Flow (Process)

The flow is the way you build your product or projects. Its design greatly informs how your team develop your product, and it should reflect the values ​​that your team and company preach.

There is no guide for designing your Kanban flow, but depending on your product, there are some best practices that can be applied from other experiences. And as your business grows and your product matures, your flow will change accordingly. When we were building our MVP at Resultados Digitais, our flow was different from today’s. Back then, we knew very little and had only 10 people on the team – compare that with today, when we have a lot more product learning, have more than 200 employees and face totally different challenges.

You should design and improve your flow reflecting on your learnings, but also on the values ​​of your company. Make sure you understand the business, its employees and the company values. Use your flow in a way that enhances and strengthens the values ​​that you want to see in your team and product. It’s a very powerful tool to spread culture.

This is only the tip of the iceberg; Kanban has numerous other features and practices. The use of Kanban and principles of lean management is extremely valuable for product development, and for teams tasked with continuous delivery. Start today with a To Do, Doing, Done flow, be sure to improve your Kanban processes continuously, and let me know how you get on in the comments!