Kanban, Lean and Agile mysteries
Kanban, Lean and Agile mysteries
Här är mina slides om Agila kontrakt från Devlin 2014.
Jag hoppas det skall inspirera fler företag och myndigheter att börja använda sig av dem, då de medför väsentligt lägre risk än traditionella kontrakt.
(Använder du Agila kontrakt idag – tveka inte att höra av dig!)
Vi har i Sverige dåliga practicies för upphandlingar och har redan halkat efter våra grannländer. Det gör att vi tappar nödvändig konkurrenskraft som vi verkligen behöver för att fortsätta utvecklas i global värld.
Slutligen vill jag påpeka vikten av att inte bara se till kontraktet utan att ha koll på två andra processer:
Detta går jag och Mia Kolmodin som framgångsrikt hjälpt flera företag med beställning igenom på vår kurs “Certifierad Agil Beställare (9-10 Mars)”, ett initiativ för att öka kundmognaden vid beställning och upphandling, både för privat och offentlig sektor.
Väl mött – här är slides från presentationen
Crisp’s Youtube channel has made a new release – introducing Concepts.
Concepts is used to let passionate people run with ideas, a different approach than that of traditional product ownership. If you do use in conjunction with a product owner, it allows that person to spend more time on the field with customers.
Ps: The mastermind behind the illustrations -> Jimmy Janlén!
More on concepts: crisp.se/concepts
Try out concepts at The Product Owner Survival Camp, 3-4 Nov
(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!
Back again from Lithuania. Great to see so many people there and a bow to the organizers putting in their voluntary effort.
Here are the slides.
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.