Olav Maassen talked about Kanban in Action. A very interesting and interactive talk in which Olaf gave a very clear insight of the inner workings of Kanban. In this blog I’d like to give a summary of this talk and also add my humble opinion along the way. I’m not going into depth of the inner works, because I’m not in the business of promoting one particular methodology. I will just be highlighting some of the basic thoughts behind the process. In the last couple of years I’ve been working as a scrum master / technical team lead. In this position I tried to apply a more agile approach to software development in the project we were doing. To accomplish this I used some of the handles I know from Scrum. Looking back at that project, with my recent acquired knowledge of Kanban, I believe things could have been done even more effective.
Effectiveness versus Efficiency
To jumpstart right away on the term effective or ‘Effectiveness’ I’d like set it off against the term ‘Efficiency’. You might work effective by working efficient. Being efficient, means you’re good at what you do. It doesn’t always mean you’re working effective. For instance if you fill out a form and you use the tab key to jump to the next field that might be the most efficient way to fill out a form. But if only the last five fields are important for this questionnaire, answering every question on the form isn’t the most effective way of going about. This is the essence of agile development. Doing what is necessary at that given time often delivers most effectiveness.
Having all the information all of the time is mandatory to be able to determine what is most necessary at that time. So this is most important to be able to work effective. It also helps to build trust within the team and towards the business, clients, projectmanagement and board.
In addition we refer to triple ‘T’ (Trust, Teamplay and Transparency) as to being the pillars of good project management. Olav divided the audience into two halves. The first half played the good part (Cinderella). They had to think up ways and elements to make project succeed. The other half played the bad part (The evil mother-in-law). They had to think of means to deliberately make projects fail. Without any trouble the bad half was able to undermine any project in no-time. Items the good half proposed were all derivatives of one or more of the three pillars ‘Trust’, ‘Teamplay’, and ‘Transparency’. These pillars are also dependent on each other. Trust can only exist when there is Teamplay and Ttransparency and the same goes for the other combinations.
David Anderson wrote down a recipe for success, containing the following ingredients:
Focus on quality – Producing quality code saves time. It is a misassumption to believe that reducing quality, writing less or no unittests, not obeying standards or eliminating documentation should speed up your throughput. Maybe there is a tiny bit of speed gained the first few days, but in no-time, eliminating quality, slows the process down exponentially.
Reduce work in progress and deliver often – By dealing with small chunks of work at a time and shipping them with a high frequency, you’re able to deliver what is most necessary at that time. This is key in building applications that really comply with the business needs. A second advantage is the ability to reduce the number of existing risks at one point in time and gain business value at a steady pace.
Balance demand versus throughput – Business needs change over time. By carefully selecting the wishes that are picked up for implementation and trying to minimize the amount of work items that are executed leaves room for change along the way while still adding value to the business.
Prioritize – In order to be able to deliver often you have to set small goals and determine what is most important.
Reduce variability and improve the process – Try to keep the team, the infrastructure and the environment as stable as possible. Adapt retrospection and learn from the mistakes that are made along the way. Adapt processes that work even if they are not always the most advised ones from a agile stand of view.
Trying to adapt these ingredients of course doesn’t guarantee success but at least it enlarges the changes for success a great deal.
When I look at Kanban tips and trics and I compare them with the ideas Scrum has on these items there are some differences but for the most part there are a lot of similarities. Neither methods are the silver bullet you can pick of the shelve to be successful in agile projects. It’s the mindset behind the methodology that make the method work. And everyone involved has to commit to this mindset. A single evil-mother-in-law-project-member can poison the beautiful fairytale.