Mattias Skarin

Mattias Skarin

Kanban, Lean and Agile mysteries

Agila kontrakt – slides från Devlin 2014 (swe)

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.

agila-kontrakt-slides2

Slutligen vill jag påpeka vikten av att inte bara se till kontraktet utan att ha koll på två andra processer:

  • Hur veta jag var jag skall beställa?
  • Hur utvärderar och väljer jag leverantör

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

Video – product development without the product owner

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

Cheers

/Mattias

Vad du inte visste om LOU – Lagen om offentlig upphandling

(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.

read more »

Slicing cheatsheet

sliced-appleOne 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.

/Mattias

Slides from Stop Starting Lean Kanban Nordic 2014

Logo LKN14

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 good decision process

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?”

“Three years”.

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.

read more »

Slides from Mix-IT

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.

Some reflections:

  • Saw a cool presentation on Prioritizing portfolios using Cost of Delay by Özlem Yüce. No doubt mr Don had an idea or two in there.. Great presentation. Read more about the case here.
  • Talking about serious things has never been easier, attended a Lego / Serious play workshop where the power of being able to talk about something (using physical metaphors) rather than against someone was clearly demonstrated. Looking forward to learn more about this. A great tool in to dismantle sensitive subjects in team environments.

I did my talk on Visualization. Next time will update with more examples. Slides are here.

The lean conference of the year – Stop Starting 2014

Stop Starting Start Finishing . Lean Kanban Nordic 2014

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:

read more »

Why you are better off using a developer than a lawyer when purchasing software

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?

  • Lack of provider skill
  • Lack of customer maturity
  • Lack of ability to utilize late learning
  • A one time shot to get any IT updates in my environment
  • I win, you loose approach – no shared economic incentive
  • Lack of communication, during execution

read more »

Coaching questions for a kanban team

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.

  • How do you prioritize?

To work on prioritized content is a human right.

  • How do you ensure you don’t work on too much?

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!

  • How do you share knowledge?

Building skill quickly is the way we build capability. If there is no deliberate thought here we cannot scale.

  • How do you improve?

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 should be improved next?

What and why? How do we track progress of improvement activities?

Catch 22 – The egoless, present and curious leader

Every successful implementation of Lean or Agile I have seen has an ingredient that is almost a contradiction.

A leader who

  • has low ego (not interested in putting himself first)
  • is present (he/she has active conversations with teams and other leaders such, as change never comes as a complete surprise)
  • is active (he takes part in building up teams, do not defer hard decisions, he notifies and challenges, using questions, when people behave differently from the values agreed)
  • curious (what is the next step, what should we try, let’s do it)

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.

/mts

Förbättra från start till mål

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)

Video from “Improving the full value chain using Lean” @ LKCE 2013

lkce_mattias

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.

read more »

Learning to communicate requirements, even Agile, the human way

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.”

read more »

Function team vs. feature team – a definition

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.

read more »

The worlds fastest CI

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.

Enterprise kanban – improving the full value chain using Lean thinking

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:

  • We improve time to market by 2x in 1.5 year
  • 95% of shipped product ideas reported value adding
  • We delivered our products without use of Product Owners, Project managers or a Project Office
    (we did however have a marketing function, so another way to put it – it can allow product people to spend more time out with customers)
  • Enterprise kanban, Concepts, collaborative design and facilitation were our main tools

Read the full case study here.

As always, always make sure you use ideas wisely in your context. Never copy, always improve.

Cheers

Mattias Skarin

Podcast: Improving interactions through the Lean value chain

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!

Slides from Keynote at Agile Tour Lithuania 2013

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.

Slides from Lean & Kanban Netherlands 2013

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! :)

Slides from Agile Eastern Europe 2013

Met a great crowd in Kiev at Agile Eastern Europe. I’d love to stay longer!

Here are the slides on my presentation on Visualization – what’s my brain got to do with it.

Slides from Lean Kanban France 2013

Just back from Paris (gotta love that town, many good memories there :)

I did my first presentation on Concepts.  Here are the slides.

/Mattias

Crisp for breakfast?

What’s this? An alien invasion? A publicity stunt? A way of sneaking Crisp into your cereals?

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.

Slides from Dare – “Visualization, what’s my brain got to do with it?”

Just got back from DARE conference in Belgium.  I don’t know how Maarten makes it happen, but I always leave with more ideas than I had when I came.

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!

Introducing Concepts

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”.

Concept sketch

The idea

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.

Concepts

Concepts helps you

  • Treating post release challenges as part of normal design
  • Decrease friction between business and development by setting clear expectations of what should be prepared before entering into conversations with developers
  • Develop a minimum specification, flexible for your context
  • Increasing the value added time of your development team by training business people to arrived prepared with the right questions
  • Increase learning by completing the feedback loop all the way to customer use
  • Sharing the work load of a product owner onto a team
  • Lower waste:
    - preventing ideas with unclear value (hidden in big requirement documents) to enter solution design,
    - less rework  after release “bugs development should have foreseen”
    - avoiding heavy documentation in the early stages of product development when uncertainty is at it’s greatest

Companies have used concepts to:

  • Keep a single thread all the way through to working at client
  • Help product owners spend more time with real users
  • Solve product owner overload scenarios
  • Remove handovers

>> Download the full article

Here are some Concept section examples

(A shortlink: crisp.se/concepts)

10 Kanban board and their context – updated!

Added a visualization combining architecture with progress follow up for more complex product development scenarios.

Visualizing progress by architecture

You’ll find the complete collection of boards here!

Cheers

Mattias

Sources of bug list misuse

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.

  • For keeping track of product limitations
  • Awaiting and aligning prioritization (to be done later since organization units use different prioritization schemes)
  • For reporting without action
  • For maintaining traceability although we do not intend to fix it (ever)
  • For dispatching to the right team
  • For learning about frequent reoccurring sources of problems (this can be done outside the bug list)
  • For pleasing every customer/user (some have marginal value)
  • For maintaining pressure on the organization (political motives)

Hope it helps!

/mts

By code thou shall present! ITAKE

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 – now in Swedish translation

Kanban and Scrum book is now available in Swedish translation, you can download from InfoQ here

Thanks to Johan Natt och Dag!

Addressing critical in deliveries from subcontractors

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.

Project with indelivery

read more »