Kanbanize Visual Kanban Software and Why Managing WIP Matters

The Visual Kanban software market is nascent, but quickly growing and gaining traction among software development and engineering teams. In that market, there are several players. In a previous interview, we spoke with Chris Hefley, CEO of LeanKit. Today, we speak with Dimitar Karaivanov, CEO of Kanbanize.

In this interview, you’ll learn the following:

• The role of visual management in software development
• The influence of the Theory of Constraints in modern software engineering – an aspect not discussed much
• Why Respect for People is important but “fragile” concept that could get lost in the development of software

Enjoy the article and feel free to read about Dimitar after the interview.

---

Software development processes have undergone quite an overhaul in the last several years. On this blog, we interviewed Mary Poppendieck back in 2007 on Lean for Software. Can you help explain the difference between Kanban Software Development and Lean for Software?

Practically, there is no difference as one is a subset of the other. Lean is the culture of doing things in a highly efficient, waste-free manner and Kanban is a concrete implementation of that culture. Lean talks about visual methods for communication, which is effectively represented by the physical or electronic Kanban board.

Identifying waste is mostly achieved through value stream maps, which to a great extend corresponds to the different states on a Kanban board. Lean talks about flow and we achieve it with Kanban by applying limits to states on the board which tend to grow inventory over time. Last but not least, lean defines important parameters like Cycle Time, Lead Time, etc. which every team doing Kanban should measure and strive to improve. This is a somewhat oversimplified picture of how these two relate to one-another, but digging deeper should probably be a separate post.

Can you tell us what Kanbanize is and what specific problems Kanbanize was designed to address?

Kanbanize in its core is a visual project tracking system implementing the lean principles of visualization, limiting the work in progress, and achieving perfection. In other words, we do Kanban software. We help big companies get visibility into every corner of the organization by providing powerful analytics and reporting modules, and at the same time make the end user happy with a great UX and almost no learning-curve.

One of the primary use cases for Kanbanize is organizing a project portfolio management system that contains a high-level definition of one or more projects. Each card/item on that Portfolio board is the parent of unlimited nested levels of other projects or Kanban boards. We have complex mechanism to notify the different levels in this hierarchy about changes in some of the projects and by that we achieve real-time visibility at the different levels. Imagine a screenshot that immediately reveals where your 500 or 1000 people company has issues. This is what we do.

For those not familiar with software development, can you share what Work in Process (WIP) is in the context of software? And, why is WIP so bad?

I have a very simple definition of WIP and I’ve found it to be quite effective across all teams I’ve worked with. WIP is any work started that I cannot forget about. The rationale behind this definition is very simple, let’s take a feature for example. If a feature is implemented, tested, delivered to a customer and the customer is happy, then I can forget about this feature and I can focus on something else. Though, if a feature is almost done sitting somewhere on a test server, we still need to put effort into it (sometimes a lot of effort) and therefore the feature is still WIP to us. The same goes with issues, support requests, etc.

I would like to reiterate that WIP is not just what we are currently acting on, but rather any work that has been started and has not been finished. Understanding this concept is crucial to minimizing the amounts of unfinished work in a system, which itself is the key to improved efficiency and productivity.

Why is WIP that bad? There are two factors which attribute to the losses we encounter when we allow too much to be happening at the same time.

• The human factor. People cannot switch context as quickly as machines do and each time we have to leave one project and focus on another, we inevitably waste time. The more complex your job is, the greater losses you suffer (no wonder why developers suffer from context switches so badly). You can read more about this here.
• The economic factor. At the moment you invest time and money into something, it automatically becomes work in progress. The sooner you make that something available to your customers, the sooner you get return of your investment. That is why it is not very wise to constantly start new things and pile them on your hard drive. It’s much better for your organization if you work on a single project, but actually deliver it (and get paid for it).

And just a closing thought on this. We at Kanbanize managed to reduce our cycle time by 700% when we applied stricter WIP limits to our process. What are you waiting for?

Let’s suppose you were a software engineer for a company that also manufactures products. You have implemented Kanban in software development and Lean is being practiced on the shop floor. You and the folks on the shop floor don’t know of each other. Would there be a benefit if lean for software folks and lean folks in manufacturing work together and even support each other? How?

The answer to this question to a great extent depends on the context, but I will provide my thoughts on a more generic scale. Assuming that the software that I work on is used by the shop floor guys, I would say that it makes a lot of sense to work together. By doing so we will benefit from the following:

• Better end product due to improved collaboration. The most effective way to build software is when you have direct access to a customer, may the customer be another department in your organization or a real external one. I have experience with a developer in a factory producing refrigerators whose job was to work on the bar code scanner software. The end result was definitely affected by the opinion of the shop floor workers and had it not been like that, odds are that the software would have been reworked (which would cost more in the end of course).
• Establishment of a PULL/JIT system. Having both sides understand lean would definitely benefit the whole process of producing software. The shop floor guys would know what JIT means and would only ask about features that are really required at the right time. This would make it more effective for the company because a) the developers won’t work on features that somebody somehow thought would be useful, but on a really needed ones and b) the customer will be able to test with the very first release, which could potentially improve the overall production process early on.
• Ensuring FLOW and short feedback cycles. In line with the previous bullet, when the customer starts testing very early in the process, they will be able to provide feedback when it could actually be taken into account. This would dramatically decrease the time to market and the overall investment required.
• Common Kaizen Events. An interesting idea that I haven’t had the chance to explore personally is to have joint Kaizen events with mixed teams. My guess is that one department would be able to exchange experience and ideas that would benefit the other and vice versa.

We at Kanbanize believe that lean is always the right choice, but it becomes a game changer only when applied at all levels in a company. Toyota understood that a long time ago and their results speak for themselves. That is why we encourage each and every company out there to start their own lean transformation today.

Kanbanize changes the process of software development. More broadly speaking, can you share about the challenges that software development teams face as they try to adopt Kanban as a software development process? More specifically, can you share about a company that overcame these challenges and what were the results?

Kanban is the simplest thing to learn in theory and the hardest thing to implement in practise. This is one of the most common traps that teams fall into and our toughest challenges as a company. A lot of people think that Kanban means just putting a few sticky notes on the wall, but this is by far not the case. As I mentioned above, Kanban is a concrete implementation of the Lean culture and you will only do it right, if you have that Lean culture in your head. Unfortunately this lean culture is so counter-intuitive for many people, that they simply cannot get it, even if pushed for years. To cut a long story short, educating the right people is the key to success for a great Kanban team.

Each company that tries to implement lean in some sort crashes into the wall of human resistance. People just hate change and that’s a given. I know about many companies that managed to overcome this issue, but many more failed to do so. Among the good examples I would quote Software AG where I was a change agent and a lean evangelist. This company has made astonishing changes and progress that seemed pure myth a few years back. The success came through unyielding management will and a network of finely trained change agents that worked with local teams to facilitate change.

Many companies talk about culture and sometimes cite the Respect for People pillar at Toyota. Can you share with us how Kanban might support that pillar in the Toyota Production System? Specifically, can you share an example of a company you’ve worked with that exemplified the principle of Respect for People withing a software development context?

In one of my blog posts I’ve touched this one specifically. Unfortunately the blog post is called The dark side of Kanban and it talks about the lack of people focus or at least the absence of any rules on that subject. When doing Kanban, it’s always a good idea to have strong managers that can pay attention to the soft part of things. Lean comes from manufacturing, where jobs on the floor are somewhat robotized and if we treat software engineers the same way, we risk to impede innovation and creativity. There is a thin line that should not be crossed there.

We know that visual management is a critical aspect of Lean. In software development, why is visual management especially important? Can you share a specific example of how Kanbanize helps organizations better visualize their work?

You are absolutely right that visualization in software development is critical. As a matter of fact, when I deliver trainings to external companies I always say: If you have to remember one thing out of this course, it should be visualization. The most important reason for visualization is the hidden inventory. In manufacturing you cannot easily hide piles of metal ready to be processed, but in software development everything is digital, sitting somewhere on someone’s hard drive. Unless you visualize that information somehow, nobody will ever know about it and nobody will ever be able to do something about it. This is a must-do for each team, not only in software, not only trying to implement Kanban. Let’s put it that way: Each team out there should visualize their work. Period J

We’ve seen software development go through phases: waterfall to agile to lean for software. And now, Kanban software development. Where do you see software development processes going next?

The one part that I feel is missing from everything we’ve seen so far is empowering people to take the lead. No process, framework, method, etc. gives any real results in that field and this has been mostly handled by line managers. We need something in that area just how people in the nineties needed Scrum. Back then they needed specific rules to apply which would surface issues to be resolved. By resolving these issues everyone became more successful and had the time to think about something else. This is what needs to happen with each software engineer feel empowered to change the world.

An aspect of Kanban that’s not discussed much is the strong influence from the Theory of Constraints. Generally, can you share with us how the theory of constraints might be relevant in developing software? More specifically, can you share an example of how this was actually done?

Great question. The theory of constraints is one of the determinants in my career development and my understanding of Lean in general. Systems thinking is something you need to grasp before you make a team or even a company successful. I will give a concrete example from my career that got me on the next level.

I was leading a team of performance engineers whose goal was to find performance regressions in all major products that the company was releasing. In the beginning we were only testing after the official release only to find out that most of the products had significant performance issues. This made us move testing earlier in the process. We started with once a month and when we had some serious automation in place, we moved to every day. Everyone would think that we’ve done an amazing job, because we were able to detect a performance issue within a day of its creation. How could that be bad?

Well, it could. J At some point in time, development teams had to choose whether they finish the new features committed to customers or fix the regression of 5% in some scenario that would probably affect 1% of the customers out there. Back then I was only thinking How could fixing the regression be bad, they MUST fix it. But later on I’ve realized that there is more than that.

If the company was able to generate more sales because of the new features, then the right thing to do would be to forget about performance (at least for a while) and work on them. If performance was a critical part of some deal and the company would have lost millions should we fail to meet the performance criteria, then who cares about the new features? My point is that we need to always think on the global (system) level and decide coming from that perspective. Creating local sub-optimums (what we partially did with the performance teams) is a misbalance in the system and one should be careful about them.

For my readers interested interested in Kanbanize, how can they learn more?

The best places to look for more information is kanbanize.com and our blog blog.kanbanize.com

---

About Dimitar Karaivanov

Dimitar Karaivanov, CEO and Co-founder of Kanbanize is a Lean evangelist and Kanban practitioner with strong background in the areas of software development and process improvement. With a career that started at a technical support center and went through system administration, quality assurance, performance engineering, software development, DevOps, management and process improvement, Dimitar understands what pains people at all levels in an organization have and embeds this know-how into Kanbanize, to make it the Kanban software for entire organizations.

Other Interviews you might enjoy: