Kanban, Lean and Agile mysteries
Kanban, Lean and Agile mysteries
(this post will be in Swedish since it is a response to Swedish legislation describing how to sell and buy software. If you still are interested, Google Translate is your best friend 🙂
LOU – Lagen om offentlig upphandling är fröet till många katastrofer för statliga och kommunala mjukvaruprojekt. Tänkt som ett verktyg för att hushålla väl med statliga medel, genom att konkurrensutsätta erbjudanden bidrar LOU tyvärr till att skapa dåliga förutsättningar för att lyckas med mjukvara.
Det knasiga med LOU är de felaktiga incitamenten: Om vi antar att de funktioner som är användbara är relativt okända i ett tidigt stadium av projektet så är default practice vid användandet av LOU att funktionerna skall specas i början och sedan skall billigast leverantör väljas. Det vanligaste sättet att jämföra leverantörer är att skapa en lång lista av den sammanlagda funktionaliten i deras produkter och sedan låta dem bjuda på minsta kostnad. Inte oväntat kommer vinnande leverantör efter kontraktet’s inskrivande att snabbt flytta på senior kompetens ur projektet till fördel för junior och vips befinner både kunden och leverantören i en långsam dödsdans där kundens användare blir förlorarna.
LOU innehåller dock ett antal möjligheter som du som upphandlare kan nyttja smart.
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?
Every successful implementation of Lean or Agile I have seen has an ingredient that is almost a contradiction.
A leader who
This is a contradiction in terms. But every great leader I have observed have had as their final goal to eventually remove themselves. A scary thought? In fact not so. All these leaders had plenitude of options to choose from for their next position. And improvement is never done. There is always a next step.
I denna video berättar jag om vikten av att se till end-to-end ledtid och att den största förbättringspotentialen hos en organisation med Agila team ofta ligger i stegen innan utveckling påbörjas.
(for english readers: In this video I tell about the importance of improving end-to-end lead time – not only think about the development portion of it)
I had the privilege of both attending and speaking at Lean Kanban Central Europe (LKCE) in 2013. (Awesome conference). In my talk I share insights and techniques useful when improving the full value chain, across functions in a software product organization.
Here’s a video on my talk.
Our human brain is way better interpreting visual information (images) than any other information. Evolution taught us to survive this way. Yet, still today, the most common form to deliver requirements is … text. In the old waterfall days it meant a lot of text, today using Agile slightly less text, but still, text. If we do it well we back it up with a conversation.
Let’s look at an Agile example, using the “As a..” syntax:
“As a buyer, I would like to buy a pair of shorts, so I can go running.”
I got the question “explain the difference between a feature team and a function team”. When I answered, I realized that many people uses the term without attaching an explaining what they mean. So here is how I define it.
Viaplay broadcasts TV over the web and to wireless devices. No need to wait for another build.. they have the worlds fastest CI!
Let me share with you how it works!
1. State normal – everything works
We can code along or have another coffee.
2. Big trouble!
Mainline is clearly broken! All hands on deck.
Here it is – live.
What happens when we apply kanban across the full value chain? What if you are a traditional company, how far can you improve before organizational structures becomes your key constraint? Can you make great products in a multi team scenario without product owners and project managers?
Let me share with you our learning of applying Enterprise kanban in a traditional company.
What we found:
Read the full case study here.
As always, always make sure you use ideas wisely in your context. Never copy, always improve.
I just got interviewed by Joseph Dager at Business901 before the upcoming Lean Kanban Central Europe Conference in Hamburg.
You’ll find the podcast here (includes downloadable as mp3 and available through Itunes)
See you in Hamburg!
It’s a busy week! But could not resist beautiful Utrecht region and Lean Kanban Netherlands with focus “Modern management methods”.
Here are my slides from the A3 Workshop, where my goal was to let the participants experience some of the upsides and downsides of using A3 in problem solving knowledge work (hint: you will need more than A3..). I wanted to elaborate on the complimentary useful tools for complex, fast paced scenarios (hint: you can do better than “just swarming”) – maybe next time! 🙂
Here are the slides on my presentation on Visualization – what’s my brain got to do with it.
Just back from Paris (gotta love that town, many good memories there 🙂
You make the call. We Go Lean at breakfast, lunch and dinner! 🙂
This picture was forwarded by Troy Magennis, a Monte Carlo pioneer.
PS: Troy is coming to Stockholm to show us how to use Monte Carlo to forecast delivery of software. A small revolution to how we do it today. If you are a program manager, manager, project manager or someone who needs to learn when I can get my things, this is the course to join.
I ran a session on visualization – highlighting our brains limited capacity capture and record knowledge (and what to think of when using visualization).
An amazingly interesting subject. I also introduce five lenses to visual work which (you as coach) can choose to apply in the order the organization is capable of learning from it Room was packed which always warms a presenters hart.
Enough talking, here are the slides!
Let me introduce a tool I’ve found useful – Concepts.
Concepts is a one page specification, in A3 format that represents a product idea of feature. It is enough to enable a prepared conversation with the engineers developing the product. Think of it as a “flexible minimum specification”.
The concept owner is a person passionate about the idea, regardless of role, who works to realize the product idea all the way to happy client.
There is no handover.
Here are some Concept section examples
(A shortlink: crisp.se/concepts)
Added a visualization combining architecture with progress follow up for more complex product development scenarios.
You’ll find the complete collection of boards here!
Bug lists have the potential to consume a lot of your organizations effort. Bugs drive re prioritization, dispatching, reporting, followup – even though they might be of one time nature and random occurrence. Whenever I encounter a huge bug list is to I ask which of these the organization will fix the upcoming release and then why they care about tracking the rest.
Over the years I have gotten a number of different answers to why the huge bug lists is maintained. I’ve found that many answers are really confusing the original purpose (to fix it) are with something else. An example can be mixing the purposes of “learning what provides a top notch service from the eyes of the customer” , “fixing the damn thing” and “tracability” – then attempting to provide answers to all of these above from the same tool.
I’ll share some of the dual purposes with you to provide you with some simple litmus tests. Each the well intended purpose below have better solutions.
Hope it helps!
Can you run a conference where every presenter has to present using code? Why not! Meet ITAKE (Bucharest, ay 30-31). A coders delight.
Our friends in Eastern Europe, Mozaic are trying out a new conference format where each presenter has to present using code. Gotta love initatives like that 🙂
Kanban and Scrum book is now available in Swedish translation, you can download from InfoQ here
Thanks to Johan Natt och Dag!
In software, one of our favorite tool to deal with uncertainty is iterations. But is it always the better option?
The last week I’ve got the question two times of how to address critical in deliveries from subcontractors. For example: hardware, preparation of land, machinery, buildings or third party platform updates. How can these be addressed? Do iterations hold the answer? Are there better options?
Let me introduce lean flow thinking and show how it can be used to improve the outcome of critical third party in deliveries in your projects.
Every organization needs to find it’s path, where to go next. Or it can choose just go “wherever” 🙂 But let’s imagine your want to grasp the state of your hope, dreams and future of your creative people to understand what opportunities to grasp and which to let go of. Let’s imagine you need to do that among a group of self going free radicals, working in different places that does not regularly meet. Wait- that sounds like Crisp 🙂 Let me share how we grasped our future vision.
Sammanfattar i min presentation från Meridiumdagen ett antal Agila kontrakt som är i bruk idag och vad man bör tänka på när man använder dem.
—————— For the English reader:
What does Agile contracts really mean? – I walk through a number of real contracts that are in use today (presentation was given in Swedish)
Det jag upplever genomgripande saknas i alla agila kontrakt är en mekanism genom vilken kunden och leverantören snabbt kan upp ett bygga förtroende. Har man det sedan tidigare är det sällan ett problem, men frågan är hur man gör om kunden och leverantören är nya för varandra. Det finns dock en enkel lösning.
Som upphandlare väljer jag ut två leverantörer. Dessa får sedan bygga en prototyp motsvarande första iterationen av produkten. Leveranören som inte får kontraktet, får betalat för iterationen. Den andra leveranören som får kontraktet.
Knepet i utvärderingen är att du måste lyfta under huven på produkten för att se ingenjörsmässighet bakom. Det är där du ser skickligheten. Glömde jag nämna att Crisp gör sådant? 🙂
If you prefer this as an article – you can download it here.
Continuous improvement always starts by observing previous results. That is our baseline for improvements forward on. We strive to improve steadily, a little at a time – 10% is great! But first step is always to accept the facts, regardless if we would have liked it to be better. It is way too easy to sweep failed projects under the carpet rather than used as a baseline for improvements forward on. A mistake easily made is to base improvements on dream targets rather than previous results, it is hard to learn something from failure to meet those targets.