There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does it compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some

How can anyone say

that they are Lean or agile when they don’t inspect and adapt.

What most companies have in common when they implement process improvement is lack of continuous improvement…..  

Do you believe a manufactoring plant is a good model for software development?

No? Then what why would you strive so hard to apply Lean in IT?
Think about the answer for a while.

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt. My conclusion is, not very suprisingly, that  it depends on the situation.

In this entry I take the Scrum T-shirt on.

I have for some time been thinking, what is best, Kanban or Scrum. I can’t make up my mind so I decided to write two blog entries, one where I have the "I love Kanban" hat on me and one where I’m wearing a "I love Scrum" T-shirt. My conclusion is, not very surprisingly, that  it depends on the situation.

In this entry I take the Kanban hat on.

Yesterday, in a post by David Andersson, he so accurately in few words managed to describe the fundaments any Lean implementation.

"In Lean operational decisions, value trumps flow, and flow trumps
waste reduction."

The value of waste reduction (over flow) is for me one of the great misunderstanding of Lean.

En kort sammanfattning av grunderna i Lean på 10 minuter. Concept To Cash, Cykeltid optimering och köer och flaskhalsar.

Lean handlar om att bli snabb genom att sluta göra onödiga saker.

Lean värdesätter det som levereras och inte det som påbörjas. Att få saker ur händerna istället för att jobba hårt.

(sorry, this article is in Swedish, because it is a response to a Swedish article. I won’t make this a habit.)

I en artikel i Computer Sweden den 3 feb står det ”siffror visar att nio av tio Scrumprojekt misslyckas”. Men de angivna siffrorna handlar i själva verket om något helt annat – att 9 av 10 personer som säger att de kör Scrum inte implementerar Scrum fullt ut. Detta säger ingenting om huruvida själva projektet lyckades eller inte (eftersom Scrum inte är ett självandamål). Denna typ av sensationsjournalistik gynnar ingen – utom möjligen tidningen som vill öka sina tittarsiffror, men på bekostnad av trovärdighet.

Låt oss därför titta på lite mer relevanta siffror istället….

These are checklists I have compiled to help my Kanban teams stay focused

"Anytime" Iteration planning Daily standup

Download as pdf

I recently got  a valid question from a collegue and it deserves an answer.
"When do I use Scrum and when do I use Lean?"

Lean predicts that work happens in a certain order. Scrum has a "chaos" approach where work can be done in best possible way, dictated by the situation.

Therefore Scrum works better than Lean in environments with rapid change, on the edge of chaos where the same solution rarely work twice.

Kanban pracitioner or a Scrum team thinking of adopting it?, don’t miss out on the "Future of Agile" conference 27:th of May.

An unique opportunity to learn from practitioners and experts about experiences and best practices for Kanban and Lean in our "Bring your kanban board" session. Joining us is David Anderson – father of Kanban.

Future of Agile, May 27, Stockholm

This is not you, right?

• Customer making changes at a faster rate then the development teams can implement
• A development team running short sprint lengths only to deliver crap to QA
• A development team promising features at a quicker rate than we can make avaliable to end customers – only to build up a queue of unshipped work
• A management team changing directions in a faster pace then company can absorb them,
• A software development company entering an Agile contract with a waterfall process

We apply agile principles to be fast and responsive to changes. Lean teaches us to "deferr decisions", agile to "change late". But doing this and turning a blind eye to real limitations we  fool ourselves to believe we can drive faster than we are able. Result? Quick steering adjustments aimed for a sports car brings the truck into inbalance and possible into the ditch.

running this?	..or this?

Min gode kollega Hans Brattberg ställde denna provocerande fråga:

Vad i Lean hindrar oss från att göra en kejda av
Req Spec -> Architecture -> Design -> Program -> Test -> Production

Med handovers hela vägen?
Utan kommunikation?
Utan Cross Functional?
Utan Feedback?

Scrum does not fit well into the fast moving world of support. There is no Sprint committment, there is just continuous work.

But support teams can go Agile. The solutions is spelled Kanban. I have coached two support teams adopting Kanban and attached is a visual representation in how we did it.

"It really helps us visualize our projects and situation"
– Team member

"The first useful thing I can bring with me"
– Team member

How support can go Agile in 5 min

This is not the only way to do it and it is certainly not the end station :). It was just the way that helped our teams to "get going" instead of talking about it.
— mattias.skarin(at)crisp.se

Here are the slides from my presentation "Vadå Lean Software Development" (Introduction to Lean Software Development) at HiQ on Oct 13. Note – the picture above (the last slide in my deck) can easily be misinterpreted when used out of context. It is not meant to imply that XP is a subset of Scrum, or

This article on DN (major Swedish newspaper) caught my attention this morning:

The title of the article is "Waiting times at Huddinge halved with new process".

We spend a lot of time helping IT companies understand how to use Lean principles to increase the speed and quality of their product development. It’s interesting to see how the same techniques are applied in totally different domains – in this case the intensive care unit at a hospital.

Excellent game for quick learning of lean principles. You can do it anywhere and anytime with 20 pennies, some mobile phones and a team of playful people.

One of the ancient mysteries of science is why toasted bread is less filling to eat than non-toasted bread.  A revolutionary scientific breakthrough was made this evening bringing us closer to the Answer,

See below for the full report.

If you’re in Stockholm Sep 25-26 you might be interested in Deep Lean. It’s a 2 day in-depth course on Lean & Agile & Scrum (see the course agenda). The teachers are Mary and Tom Poppendieck, Jeff Sutherland, and myself. Mary and Tom coined the term Lean Software Development and Jeff invented Scrum (the most

In Scrum it is often perceived that planning takes place on sprint planning day. Getting the required parties in the same place and do planning is a good way of making real time decisions. But getting people together is a dounting or impossible task and this also neglects some of the thought processes that needs to take place before stories are estimatable.

Because of unclear definition of benefit of removing technical debt, PO and teams risk move into a standstill regarding activities to to remove it. This is counter productive, we should remove thresholds of quality improvement activities, not introduce them. So let’s look into a simple definition that can help out.