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 kanbnize.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:
Lean Leadership Interviews |
|
|
Jeffrey Liker, NYT Best Selling Author, Professor, and Author of the Toyota Way |
Jeffrey Liker, author of The Toyota Way, shares his thoughts on Toyota Kata, why sometimes root cause analysis isn't necessary, and what else he is excited to learn - even after 30 years of being a student of the Toyota Production System. |
|
|
In this Podcast interview with Eric Ries, the author of The Leanstartup, we learn about the how he's applied Lean principles to starting companies. He also tells us about his consulting work with GE and how GE, worldwide, has applied Leanstartup throughout all its divisions and is considering Leanstartup as its new Operating System for the company. |
|
|
Michael Balle is a leading voice in Lean. In this interview, he shares with us his thoughts on Lean, tells us about his book, and spends a good amount of time discussing Respect for People. |
|
|
This interview with Dr. Bob Emiliani covers several aspects of Fake Lean versus Real Lean. There are real insights here from the "Lean Professor". |
|
|
Lean Branding is an application of Lean principles to branding. Read her provocative and practical approach to brand branding using the principles of Lean. |
|
|
Robert Martichenko is the Founder and CEO of LeanCor - a lean logistics and supply chain company. He is also the author of the book "A Lean Fulfillment Stream", published by the Lean Enterprise Institute. In this interview, he shares with us how Lean can be applied effectively beyond the 4 walls of manufacturing and outside the office, but infused into the entire supply chain. |
|
|
Leanpub is an innovative approach to book publishing, where Peter believes that lean principles apply. He claims that writing a book is essentially a startup. And, the worst waste of all is writing a book that nobody wants. Read more to learn how to apply lean to the world of book publishing. |
|
|
Keith Sparkjoy is the Culture Officer at Pluralsight, a Utah company that raised $135 Million in 2014 - an unprecedented amount of venture capital. And, here's the really cool part, as the culture officer, he's trying to transform his company using Dr. W. Edward Deming's teachings. |
|
David J. Anderson is the pioneer of the application of Kanban for creative knowledge work. His methodology and approach has had widespread acceptance and adoption and in this interview he shares results from companies that have tried his approach and other lessons learned. |
|
|
Dimitar Karaivanov is the CEO of Kanbanize, a visual kanban system designed for creative and knowledge workers. In this interview, we discuss the product and its many uses and how it embodies the principles of Lean. |
|
|
Chris Hefley is the CEO of LeanKit, a company that provides Virtual Kanban software for software development teams and knowledge workers. Reah his interview and learn what led to the development of LeanKit and the role Lean and the Toyota Production System plays. |
|
Dan Markovitz, Noted consultant and expert on Lean for Office |
In this interview with Dan Markovitz, we learn why he believes that everything is connected to the customer through the office. Based on this belief, he feels that Lean for Office makes the most sense. Read and learn how he's implemented Lean for the Office. |
|
|
Jason Yip is a noted thoughtleader in software engineering. As a consultant, he helps software engineering organizations get better. In this interview, we learn the state of software engineering and the role of Agile, Lean for Software and Kanban. |
|
Matthew May, NYT Best Selling author, consultant, and expert on Toyota Production System |
Matthew May is an author and influential voice in Lean and also Design Thinking. He worked close to a decade at University of Toyota to help codify the Toyota Production System. In this interview, he shares with us his thoughts on his experience and what we can learn from it. |
|
Mark Graban, Best Selling Author and expert on Lean for Healthcare |
Lean Healthcare expert Mark Graban stops by and share his thoughts with Shmula readers on how Lean can be applied to arguably the most important industry in the world, healthcare. |
|
Art Smalley, 15 Year Toyota Veteran and authority on Toyota Production System |
Art Smalley is one of the most honest and influential voices in Lean. He was the first American to work in Japan's Kamigo plant, the plant where Taiichi Ohno began the Toyota Production System. He shares with us his thoughts on the Lean Movement and where it is going wrong. |
|
Jeff Gothelf, Author of Lean UX, applying Lean for User Experience |
Lean is being applied to every facet of business. Jeff Gothelf shares with us his thoughts on applying Lean for user experience, or Lean UX. |
|
|
Cecil Dijoux shares with us his thoughts on applying Lean to IT, definitely a must-read if you are in the information technology space. |
|
Brent Wahba, Author and Expert on applying Lean for Sales and Marketing |
Brent Wahba is a fellow at the Lean Enterprise Institute and shares with us his thoughts on Lean for Sales and Marketing. |
Interview with Tony Hsieh, CEO of Zappos |
|
Tony Hsieh, CEO of Zappos |
In December 2008, I was fortunate enough to interview Tony Hsieh, CEO of Zappos. In a 5 part series of interviews, we discuss the Zappos strategy and Tony answers questions on why he chooses to focus on the customer and how he sees that as strategic. |
Interviews with Customer Experience Experts |
|
 Mark Roenigk, COO of Rackspace and Board Member at the Bill and Melinda Gates Foundation |
Rackspace Interview on Customer Experience: We interviewed Mark Roenigk on June 10, 2013. We discussed the Net Promoter Score and also topics around process improvement and how Rackspace places the customer first. |
Shep Hyken, Author and expert on Customer Experience Strategy |
Shep Hyken Customer Service Interview: We interviewed Shep Hyken on June 3, 2013 and discussed topics close to his heart - the customer. We focused our discussion on customer service and how focusing on the customer is strategic, not just tactical. |
Annette Franz, Customer Experience Strategist and Survey Design Expert |
Annette Franz Gleneicki on Customer Experience Strategy: Annette Gleneicki is a customer experience thought leader and Director at Confirmit, a voice of the customer platform. We discuss her thoughts on customer experience and the direction of the overall field. |
|
Michel Falcon on Improving the Customer Experience: Michel Falcon is a former executive at 1800GOTJUNK and was the person who propelled 1800GOTJUNK to become a customer service powerhouse. In this interview, we discuss what he did and the lessons he learned. |
Adam Ramshaw, Consultant to fortune 500 companies on Customer Experience |
Adam Ramshaw, a customer experience consultant with Genroe, explains the relationship between continuous improvement and customer experience. |
Leadership Interviews |
|
Aza Raskin, Author, Startup Founder, and Son of Mac Inventor Jef Raskin |
This is a multi-part Interview with Aza Raskin, on the Humane Interface.
|
Mary Poppendieck, Author and codifier of Lean for Software Engineering |
In this multi-part interview with Mary Poppendieck, the pre-eminent evangelist and teacher for Lean for Software, explains Lean Software Engineering.
|
|
The inventor of Clocky, Gauri Nanda, shares with us her thoughts on innovation and the birth of Clocky |
Gretchen Rubin, Author and evangelist of Happiness |
In March 2010, I held a 2 part series of interview with Gretchen Rubin, the author of the Happiness Project. Her answers to reader's questions on a variety of topics centering on happiness will enlighten you. Gretchen Rubin, the author of The Happiness Project, shares with us here thoughts on how to be happy and what our part is in choosing to be happy.
|
|
Spencer Rascoff, the CEO of Zillow, shares with us his thoughts on this interview with Zillow back in June 2006. |
|
Josh Coates, the founder of Mozy, shares with us jokes and the innovation behind Mozy. |
Lloyd Hildebrand, Physician, Entrepreneur, and Enemy of Preventable Diseases that cause Blindness |
Lloyd Hildebrand describes Diabetic Retinopathy and how his company, Inoveon, a Telemedicine Company, aims to eradicate diabetic retinopathy. |
|
Ryan Kiskis of xFire, the developer of World of Warcraft, explains his thoughts on innovation. |
Brian Hansen, Product Director, Kaboodle, the first pinterest |
Kaboodle, was clearly the predecessor to Pinterest. We learn about Kaboodle and the innovation behind it. |
|
Mark Jen, VP of Product Management at Plaxo, a Contact management company, the predecessor to Linkedin speaks to us about innovation and the business of business networking. |
Samuel Adams, Community Director and expert on all things word of mouth |
Bzzagent, the word of mouth marketing company, explains the power of the buzz. |
The post Kanbanize Visual Kanban Software and Why Managing WIP Matters appeared first on shmula.