1. The Beginning
I co-founded Kanbanize because I envisioned the exponential adoption of the Kanban method some 6 years ago (the name is not a coincidence). Back then (2010), I became a Lean champion at a big German company. We were a team of Lean thinkers helping the RnD department (and to some extent the entire company) change course from Waterfall to Lean and Agile delivery methods.
To this day, I am not sure how I got this role and to be quite open, I have no idea why Christoph chose me before other much more experienced managers in the company. I guess it was a stroke of luck that would later prove even more significant than I anticipated at the time. Christoph came from the biggest German software company - SAP. He was famous for achieving outstanding results there and that’s why our CTO invited him to take up the SVP position.
I met Christoph for the first time a couple of months after he joined the company. We talked about my team, which was responsible for the performance of the product suite. I remember showing off the good results that we had got during the past two years, but he didn’t seem too impressed. I realized later that he was probably not that interested in what we were actually doing, but focused on assessing the people he could count on later. He had plans that none of us could have suspected.
His plans turned out to be simple but revolutionary for the situation that we were all in. He was on his way to establish a promotion process for the entire product suite (20+ products working together). This basically meant the following:
1. Each product team had to have a nightly build and as many automated tests as possible.
2. All product builds had to be integrated each night and tens of thousands of automated tests were executed against the entire product suite.
3. The teams were not allowed to work on other things unless their builds and tests ran smoothly. Even if a single test was failing, the issue was marked as a blocker for the whole suite and had to be resolved with the highest urgency.
Now, I want you to evaluate the chances of success of this approach, while keeping in mind that it took some of the teams more than a month to build their products. That’s right - the last successful build for some products was more than a month old and these same guys had to not only build every day, but also run automation tests, none of which could fail. Quite revolutionary indeed.
In the beginning, people thought Christoph was not serious about the promotion process and even ridiculed his approach. However, they soon realized that he wasn’t joking and started working hard to get this whole thing done. It took everyone a lot of time to get there, but after an year things started to look better. We had a well-oiled promotion process of consistently producing stable and well-integrated suite builds, representing 20+ products working together.
A lot of success followed. We were able to release a super high-quality release on time and that had not happened for many years prior to the changes. We started adding more tests to the promotion process - performance tests, upgrade tests, installation tests, etc. In my team we were able to detect a performance regression on the next day after the release was introduced. Just think how many companies have performance tests in the first place and then think how many of those companies can detect regressions throughout the promotion cycle of 20 products. We were nailing it down every single day and, in fact, there were a lot of performance bottlenecks fixed without even raising promotion blockers for them. This was a sign that the product teams could actually spend time improving the product’s architecture and not just put out fires, as they were used to.
Watching all of this from a first person perspective and actually being an active part of the transformation got me really fascinated. I was amazed by the effectiveness of Christoph’s ideas. That got me further into Lean and I started to develop and test my own ideas in the teams with which I worked. That’s how I learned about Kanban and this was the element that changed my life for good.
...
Meanwhile, one of the main initiatives that we had with the Lean Thinkers team was the “Feature Management” topic. The problem there was that there were many user stories distributed across 20+ teams and there was no reasonable tracking as to of what was happening on the feature level. In other words, only the corresponding product manager was
partially aware of what was happening in the team and there was absolutely no way to figure out the progress outside this group. Apart from that, there were many cross-team features that were usually delayed, due to the lack of synchronization and focus holding back some of the teams.
What we accomplished was to establish a mechanism that would allow us to track the overall progress of all feature work for more than a dozen different products, split into five investment areas. This mechanism would allow us to report weekly on how many features have been completed, how many were being worked on, how many user stories were in progress, etc. all of this distributed by investment area (management wanted to know where money was being invested).
All the data was presented using a monstrous excel spreadsheet, which was generated once a day from a central database. There was a working student whose primary job was to get the data extracted from a tool starting with J and then get it imported into the central database, from which the spreadsheet was seeded. Then, we would use this spreadsheet to run our weekly meeting, during which we would come up with observations and suggestions for improvement.
There was also a separate meeting of all VPs of the corresponding investment areas to discuss the feature status and take actions to unblock given features, if they appeared stuck.
This solution worked really well compared to the chaotic environment in the past, but, of course, some things were far from perfect:
Being involved with the Feature Management initiative, while at the same time experimenting with Kanban in my teams, made it really easy for me to see that using a Kanban system on the global feature level would solve a lot of problems (and expose a lot of new ones). Had we implemented such a system, we could have:
Pursuing this idea further, I started searching for better alternatives that would allow us to map this whole management process. Looking at the different tool offerings, it became evident that tooling support was years away from what I envisioned my organization needed. That was understandable. After all, we were quite innovative with what we were doing and tooling had not yet caught up.
That’s how Kanbanize was born – out of necessity. I was lucky to have Christo, a childhood best friend of mine and now CTO and co-founder of the company, working on the first version. He came up with a prototype after six months of work and I went ahead to demo it to the Lean Thinkers team. I actually proposed Kanbanize as the official feature management instrument in the company, but the project didn’t fly. It’s just that the company needed much more than we could offer with the first immature version of the product (this was more than 5 years ago).
However, Christo and I could recognize the potential of this solution and we could probably see what others didn’t, so we decided to quit our jobs and completely dedicate ourselves to the dream to “Kanbanize the world”. This was, and still is, the best professional decision I have ever made in my life.
Getting an investment from a local venture fund (thanks Eleven!), on-boarding Biso as a third co-founder and quitting our lucrative jobs was the easy part. When we found ourselves in the situation with an ugly beta-version, just $125,000 in the bank and a total revenue of $3,000, we realized that we needed to act fast. We just had to find ways to make maximum impact with the least amount of money possible and make the company profitable. Oddly enough, this looks pretty much like the situation which Toyota were in when they started their automotive projects. They were a small Japanese company that wanted to build cars, but didn’t have a lot of money and know-how. That is how they created Lean - they just didn’t have the luxury not to.
Full of fear and hesitation we continued with our endeavor to Kanbanize the world. We became a team of five guys, the three co-founders and two employees. We were getting some traction, but it was far from what we needed. That’s when Christoph came back into the picture.
One day, I got an unexpected call from the HR manager of the office in Sofia. She told me that Christoph wanted me to take the position of a Managing Director (the position from which Biso had resigned in order to join Kanbanize). I declined right away, because I was fully dedicated to Kanbanize, but I felt I should thank Christoph for this generous offer. I sent him a short “Thank you” email. He replied. I replied again, and a couple of months later he became an investor in the company. After all, it was a company conceived on the basis of his ideas, so his place on our board was a well-deserved one.
Shortly after that, things just started to happen and although it was not easy, the world is a much better place now. But if there is one thing that made us succeed, it is the Lean Thinking that we’ve mastered so well. My goal for the case study is to convey as much of this “Thinking” as possible. Learning through experience is priceless, but if I could save you even a month of mistakes, I would consider my mission successful.