3. Case Study: Lean Software Development at Kanbanize
Mastering Lean has been our task at Kanbanize for the past six years and, in this chapter, I am going to share what we’ve learned and what is still a challenge. This is going to be a very practical course and I hope you will find useful tips that you can directly apply to your work.
Before we start, I would like to quickly go through the reasons why Kanbanize was created in the first place. The main idea for the tool was to ease the process of breaking down bigger chunks of work into smaller pieces and to ensure seamless tracking not just on the user story (task) level, but on the feature/project level too.
The issues that Kanbanize was meant to tackle were and still are:
1. Lack of visibility into the progress of individual features (or projects).
2. Too much context switching between multiple projects or tasks.
3. Slow development processes and overall poor productivity.
4. Lack of mechanism to prevent teams from uncontrollably starting new work and therefore harm the overall performance of the company.
5. Inability of the product management to proactively work with the engineering teams due to the lack of real-time status updates.
6. Lack of actionable metrics to be used for continuous improvement (Kaizen) initiatives.
7. Lack of consistently up-to-date status reports available not just for the management but for everyone involved in the project.
8. Hard to use tools that were never meant to be used by product management, but just engineers.
9. Show what engineering is working on so that product management won’t always think that developers are slow and lazy.
10. Product management engaging with individual engineers directly, due to the lack of visibility of the actual progress.
It took us more than ten years at corporations like SAP, Johnson Controls, Software AG, ProSyst and six years at Kanbanize to get to where we are today and it won’t be exaggerated to say that we are still in the beginning of the journey. However, knowing how much effort and knowledge it took us to get to that stage, I would like to share some of our experience, so you can make the transition not in six, but in probably one or two years.
Quick Company Overview
We are a product company and for the moment we are working on a single product, but we may change this status really soon. Our release takt time (how often we deliver value to our customers and how often they are ready to accept it) is one month, which means that we roll-out new features to all our users every four weeks or so. Some of you may recognize a Scrum sprint here, but what we do is actually quite different. Instead of planning what we will be able to accomplish in a month, we do our best to accomplish as much as possible and, when the takt time comes, we just release what has been completed. This is a fundamental difference between Agile/Scrum and a Flow-based method, such as Kanban. I urge you think more about that, it may sound like a minor difference, but it is, in fact, a huge gap in productivity between these two approaches.
Our monthly release goals are:
To give you a better perspective about the company structure, let us explore what service teams (or also services) we have in the organization and how they interact with one another.
Service teams (at Kanbanize)
The use of the word “services” is intentional. We do have teams in the company, but we think of them as services. A service has an input, processing steps and an output. In order to have all services working well together, we have established rules to control how services take input from other services, how work is actually being completed and what the output should be. We can compare our company to a computer program that has the different modules talking to one another via predefined interfaces. We do this despite the fact that we are all in the same office. The support person may be sitting next to you, but instead of asking them to do something for you, we insist that people create tickets in the Support Kanban board, which is essentially the input for support. The same principle is with each and every service in the company, be it marketing, sales or product management. This does not mean that we discourage face-to-face communication. There are many situations when filing a ticket and discussing it personally is the right thing to do and we do it quite often.
One feature we have in Kanbanize, which many users consider a limitation (at first), is the predefined sections of the Kanban board. If you try to edit a board in Kanbanize, you will see that there are three sections on that board - REQUESTED, IN PROGRESS, and DONE.
Requested, In Progress and Done areas in Kanbanize
Why would we force everyone that uses our software to have to choose which column belongs in which area? The answer is quite simple - each Kanban board is meant to be a service and each service has an input (REQUESTED AREA), processing steps (IN PROGRESS AREA) and output (DONE AREA). Having this separation, we can perform a much more sophisticated analysis of the data in the board and provide feedback to the users.
Unsurprisingly, all services within our organization use Kanban (and Kanbanize) to do their job. It is our universal delivery tool, which, integrated with email, turns out to be a really powerful system that can be employed to serve various goals. However, this book is about product development, so we will mainly discuss the services marked with green in the image above and only partially touch on the orange ones. Let us get started...
Product Management
As shown on the Figure above, product management is one of the central services in a product company. It is practically the bridge between product development and sales/marketing. Being a central service, product management has to take care of multiple initiatives such as:
So how does a product manager come up with the product strategy in the first place? How does she capture ideas, in a way that is easy to work with, without spending too much time maintaining huge backlogs? What can be done to easily report on the progress? What metrics are important?
These are all important questions and we will try to answer them all with concrete examples from our daily work. First, we will go through the backlog management, then we will cover the actual delivery model, which is in essence an Upstream Kanban implementation, and we will finish with a set of important metrics to monitor.
The Product Backlog Board
According to Lean, maintaining an ordered list of ideas (backlog) is waste. It is waste because working with hundreds of different ideas, always trying to refine them and prioritize them, takes time. If they never get implemented, this time is simply wasted. However, you still need a way to capture your ideas and customer feedback.
We do that with the so called “All Features” Kanban board. This is where we capture all the ideas that we come up with as well as the customer feedback we receive. The board structure looks like that:
The Structure of the Product Management Backlog in Kanbanize
The explanation of the columns listed above:
This is how the actual board looks in Kanbanize (this is a huge board. In order to get a sense of it in its entirety, it has to be minimized to the point where nothing is readable, sorry).
The Product Management Backlog in Kanbanize
Let me ask you a question. Can you point out the area where we get most requests/ideas for? I bet you can. Can you point out the second and the third? I think you can do that quite easily too.
You must be seeing the benefit of mapping your backlog in such a visual way. The keyword here is seeing, because you can get a lot of meaningful information out of the board, despite the fact that you cannot read a single character. Visualization of work is the first core practice in Kanban and this example is just further proof that visualization is a really powerful tool.
Another effective approach, which is quite specific to the use of Kanbanize, does a really good job for us too. It is a sort of voting system that allows us to immediately see which requests are most popular. The realization is really simple - whenever a customer requests a new feature, a new card is created on this board. If the feature has been requested before, this means that such a card already exists on the board and, in such cases, we just create a subtask in that card. In other words, a card with no subtasks has been requested just once, but a card with four subtasks means that the feature has been requested five times in total. Here is how the first swimlane (high priority) of the board looks in reality:
The Product Management Backlog in Kanbanize with Subtask Details
Visualization is, once again, very helpful here (I have obscured the subtasks text, because this is real communication coming from customers). We can very quickly see which of the requests are most popular by just comparing the height of the different cards. The cards with more subtasks are larger and this directly means that more people have requested this enhancement. Now comes the “sexiest” part. We have a runtime policy which counts the number of subtasks on all cards and if a card has up to 5 subtasks, the policy moves the card automatically to the second swimlane. Another policy is configured to move the cards with 5+ subtasks to the first swimlane (high priority). This is how we automatically maintain a list of the most important features to work on. Here is how the policies look:
Subtasks automation policy in Kanbanize
Subtasks automation policy in Kanbanize
The only thing needed here is the discipline to consistently capture requests as subtasks and attach them to the correct card. It takes some time, but unless you use an automated voting system, there is probably nothing more effective than what is suggested here. We are not big fans of automated voting systems because feedback is only meaningful when you know who gave it. With automatic voting systems you rarely know this information and, at least at Kanbanize, we are hesitant to take decisions based on such feedback.
One potential issue with this approach is the fact that information may be duplicated if more than one person works on such a board. That is why you should always use keywords in the title of the card in order to make it easy to filter. What we always do is filter by a given keyword, check if such feedback already exists and, only then, decide whether a new card should be created or a subtask should be attached to one of the existing cards.
The Feature Management Board
In the previous section, we explored how ideas and feedback can be collected and prioritized in a visual backlog. In the current section, we will see how we actually run the service that feeds the development teams with work.
The board where we track the progress of features is called “Kanbanize-features Roadmap”. It is not a roadmap in the real sense of the word, but provides some generic overview about when features can be expected on production. It is important to mention that this board is a sort of MASTER BOARD and it works in combination with other boards. In our particular case, the other board that is involved in the product development process is the board of the development