Kanban, Lean and Agile mysteries
Kanban, Lean and Agile mysteries
One of the key challenges for any organization moving to a Lean flow is learning to slice bigger things to small. If you practice this long enough this becomes second nature and you stop thinking about how you do it. The good news is this skill can be taught and to show the dimensions available for to consider I put together this small cheat sheet.
I use it as a reminder when training product managers, marketing people, architects and senior developers to slice product ideas, projects, market initiatives and architecture changes to smaller pieces. It builds on ideas from Ellen Gottesdiener, Henrik Kniberg and Bill Wake.
Download the slicing cheatsheet.
Had a great day at Stop Starting Start Finishing – Lean Kanban Nordic. It is cool to see how far companies have come in applying Lean in software, especially experimenting with how to tie together the full value chain. Saku Tuominen really challenged us to think make innovation actionable and not put it into a process, I couldn’t agree more, I hope the Lean Kanban community will keep challenging itself and our sourrounding. There are many great things presented this day, it deserves a summary post in the future.
Together with Susanne Karlsson from SMHI I presented an Enterprise Kanban case study. I hope it can inspire both companies and government departements to adopt end-to-end flow thinking.
Here are the slides (In Swedish)
Here are the slides (English version)
A fundamental component for fluid operations is an organization’s ability to solve problems and make decisions. Any change or transformation cannot move faster than it’s ability to make decisions and communicate these. This is key if we realize that living with changes is the future status quo of operations.
Many years ago when I was still at University I got to meat a leader at production facility at Volvo, he asked us,
“How long time does it take from when the management team has made a decision and a worker on the shop floor grasps what this means?”
Without a doubt, this is way to slow for product development and software. But it puts a finger on the starting point for a normal, traditional company, before any lean or agile transformation begins. So, in order to succeed with a transformation that will challenge existing (often plan based structures) we need a better decision & communication process.
Just back from Mix IT in Lyon. A bit rare to visit a French conference so was cool to meet people from the French community and see what they are up to.
I did my talk on Visualization. Next time will update with more examples. Slides are here.
This years Lean Kanban Nordic conference will be something extra. The focus in on improving the full value chain, from concept to cash. You will get an unique opportunities to listen and discuss with practitioners sharing their experience of how they have improved their companies using Lean thinking. For example, learn:
The use of traditional contracts when purchasing software carry a flawed assumption – thinking the contract is the right mean to regulate risk.
The insight is key risks are : skill of the provider, the maturity of the client (yes you!) and ability to communicate honestly during the project. Few of these are effectively regulated using traditional contracts focusing on features, time and money.
Which are the key risks when purchasing software?
Kanban is easy to set up, maintaining and improving is harder!
When I visit a kanban team, I use these questions to check they know what they are doing. They are helpful since they are not tool focused, rather verifies that there is a tactic being used. After each question I add “please show it to me” to check it’s a working practice not a paper practice.
To work on prioritized content is a human right.
This is what WIP limits in kanban are for. But you might have evolved to other techniques. This verified that you have a deliberate tactic how how to handle this. Maybe you simply par program every task!
Building skill quickly is the way we build capability. If there is no deliberate thought here we cannot scale.
How do we learn about our capability over time? How do you act when if it drops? Typically lead time measurements, queue size in front of team and quality metrics are helpful here. I look to see they are fact based. Simply doing team retrospectives is not enough, we need external and capability feedback too.
What and why? How do we track progress of improvement activities?