Kanban has been used in manufacturing for over 70 years and is becoming increasingly popular in the software development industry. In an interview with our Executive Vice President of Operations Jonathan Hansen, he explains how the Kanban Method works and the role that it plays in Thumbtack’s success.
L: How is the Kanban Method different from other agile methodologies?
J: Other agile methodologies, including Scrum, offer a prescribed process for delivering projects that are meant to ensure project success. However, the needs of each customer and project differ widely and often need to be adapted from those prescribed processes; for example, some projects require frequent incremental delivery of software to validate product/market fit, while others require balancing expedited bugfixing with planned feature development. The Kanban Method allows the creation of customized processes that are continuously improving, and are able adapt to each project’s actual process needs, by focusing on two things: visualizing the work as it actually is (not just how you idealize it to be) and limiting work in progress.
Because of its inherent flexibility, this method can work as a way of connecting two different processes. At Thumbtack Technology, we have a default way of delivering software projects based off our 10 years of experience in the business. Our customers have their own context and ways that they like to work and sometimes, it isn’t exactly the same as ours. Since we’re a geographically distributed team, a lot can be lost over time zones and language and cultural differences without the ability to visualize project status. By visualizing the work, it makes sure that we’re all talking about the same thing.
L: What does this method mean in terms of organizing large projects?
J: Large projects have lots of different people and software components involved, the dependence between the components being built is not always clear and the coordination between team members can be difficult. Some agile methodologies don’t scale particularly well on their own beyond 8 or 10 people, whereas the Kanban Method allows companies to manage very large and complex software projects. We have effectively used the Kanban Method to manage teams as large as 25 people. Because this particular method puts the focus on managing the work itself and not just on individuals reporting, it scales more easily and effectively.
L: What does this method mean for companies who are pivoting and changing course frequently?
J: The challenge even with some Agile methodologies is that they don’t necessarily prevent teams from committing to the work that they’re going to be doing very early in the process; changing course in the middle can be very difficult. For companies similar to our customers, who want to do something new and innovative, they’re often operating in the space of unknown unknowns, where the key for them is to release software as early and cheaply as possible using minimum viable products to enable discovery. By releasing early and often, they can adapt based off what they’ve learned by putting the product out in the marketplace earlier rather than later.
L: Does it speed up or slow down getting to market?
J: Kanban can speed up getting to market dramatically. Besides visualizing the work, focusing on limiting work in progress is key to enabling this. When a team has too many things in progress, it will do all those things slowly; when a team focuses on a smaller number of items, it will finish them more quickly. One of the slogans within the Kanban community is: “Stop starting and start finishing,” one of the focuses of the Kanban Method is to finish the things that you have in progress rather than taking new things on.
L: Are there times where Thumbtack takes a waterfall approach?
J: Definitely, in fact, the waterfall approach is not in conflict with the Kanban Method, and is a reasonable starting point from which Kanban can improve a company’s work. When a problem we need to solve is very well-defined, well-known, or something that we’ve done before, for example, building an email marketing system, the problem set is very well-known in advance and you can achieve economies of scale by doing upfront planning. However, most of the time in software development, upfront planning is much too risky because at the beginning of the project you have the least amount of information about what end customers actually want. If you’re in a place where you’re making most of your decisions early based on assumptions and not facts, it can be very wasteful because by the end of the project, you are only then getting feedback from customers about what you should have built. In a world where you have lots of information at the beginning and that information doesn’t change much over time, then it’s not as important to be able to make decision later on because the information stays relatively steady, however this is rare in software development.
L: What are the top 3 ways that you train your team and customers to work with the Kanban Method?
J: Since Kanban is an evolutionary change management method, you start with the process that you are doing now. The first thing that we do with our customers is value stream mapping, which is taking a deep look at what the project really is, mapping out the actual process visually by surveying each person involved with the process with the following questions: what are the things that you do, what happens before and what happens after?
Based off this, we get a clear idea of how work actually gets done. Second, we make a visual map of this on a Kanban board and map the work against that process that the customer defined. Last, we look for bottlenecks in the process and try to find a way to use work in progress limits which leave space for a team to work on fewer task at a time is a way to achieve flow through the system.