Crisp's BlogPage 27

This week, we have Mary Poppendieck with us. She held an evening seminar which inspired me to think about the differences between Lean and traditional project management. I also am inspired by the questions I get from my spouse on this.

I thought that it would be interesting to do a side-by-side comparison between the two. I am no process expert, I am just a programmer who has been the subject of 30 years of different processes. I have seen DOD 2167, RUP, PROPS, PEJL, XP, Scrum and a few others. So this is just my humble opinion.

See also what Henrik Kniberg wrote earlier in his blog.Continue reading

This other day, I stumbled upon an article by John Seddon  – "Rethinking Lean Service" which had been laying around in my disk space for a while.

It struck me how these principles can be deployed using a Kanban system:

• design against customer demand : create the kanban board starting with the demand
• focus on value creation over cost elimination: set highest priority in completing work before accepting new. Use WIP limits to ensure that is happening.
• know the actual time it takes to complete the transaction as "one stop" : learn the cycle time of flow and use this to plan resources rather than spent time

Maybe Kanban is well suited for services?

If you enter the Crisp office you will see these two A3 papers on the wall (click picture for bigger version)

Here is an english translation of these pictures.

The first picture is titled "What is Crisp?". It defines our purpose.
The second picture is titled "Crisp strategy". It defines how the company works and why.

Read on if you are curious about how and why we created these simple A3 pictures, and why it has had such a strong impact on our company.

Next week is full of interesting and fun events! Mary Poppendieck, Tom Poppendieck, and Jeff Sutherland are doing the following events with me in Stockholm: Monday – Tuesday: Certified ScrumMaster course Tuesday evening: Introduction to Lean Software Development Wednesday: Deep Lean The events are all fully booked but you can still register and get on

Me and Henrik’s book have now been translated to french.

Through the admirable effort of Claude Aubry, Frédéric Faure, Antoine Vernois and Fabrice Aimetti, you can read it here:

http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/

Mary Poppendieck used this definition in our Leading Lean Software Development course a few months ago. Very nice and concise definition of lean. What is Lean? Deliver continually increasing customer value Expending continually decreasing effort In the shortest possible timeframe With the highest possible quality A journey, not a destination.

(see bigger version here)

How do you go about converting a development team from Scrum to Kanban? Can we benefit from incremental improvements in projects under high pressure?

Here is a case study of a team who transformed from Scrum to Kanban and managed to save a derailing project. I hope it can inspire others to experiment and improve.

Some of the things I learned:

• Incremental improvement  works, even under high pressure
• Key problems are typically cross functional. The better you are in building a cross functional momentum – the faster you’ll overcome them
• Kanban works as a tool for incremental improvement
• Quality over speed – always more important than the tool

(… and I have a far way to go until I can order a proper cup of tea and a croissant 🙂

Anyway, here’s the link:

Converting a Scrum team to Kanban

I am currently, after going overland from Scala Days in Lausanne by hitching, train and boat across the English Channel, in London for the NoSQL Europe conference today and tomorrow. I will try to blog from every session. It might be a bit incoherent and inconsistent, but it’s all I can offer. You can also

On behalf of the Agile Alliance I’m happy to announce that the Agile Manifesto is now open for translation! So far it has been translated to Swedish and Japanese, more translations are underway. See the Agile Manifesto Translation Program for more info & how to contribute.

Nu finns Agila Manifestet på svenska! Detta dokument skrevs 2001 av 17 experter inom mjukvaruutveckling och startade en ny epok inom branchen. Författarna bakom detta formade samtidigt organisation Agile Alliance med visionen “We support those who explore and apply Agile principles and practices to make the software industry productive, humane, and sustainable.” Som styrelseledamot i

The other day I held a three-hour workshop, an introduction to JavaFX for some colleagues. The great thing about doing it, is that it forced me to answer the question: why is it necessary to create a new language just for GUI?

(Sorry to international readers. This is a comment to a notice in a Swedish magazine. That’s why I write his in Swedish)
I dagens Computer Sweden skriver Lars Danielsson om två stora Agila projekt och vad de har gemensamt. Som insider kan jag avslöja fler saker de har gemensamt.

Is this years final series in the Swedish hockey league, there is one team that standing out from the crowd. They are more stable, persistent and thorough in every part of their game than the other teams.

Today I stumbled over this comment from one of the players. It highlights a mindset I have seen in both software and sports team that basically felt unstoppable.

"If I am going to think about this victory on the way home? No. I am only going to think about the details that is going to make us better in the next game" 
           – Jimmie Ölvestad

Join me in this exclusive 3-day workshop where experienced Agile/Kanban practitioners, coaches & project managers share knowledge. The workshop is led by David Anderson and limited to 8 participants. Click here for more info & registration. Only 2 seats left!

The TDD Tetrahedron has reached version 1.0.

As I write this, we have a course on advanced TDD with Robert C Martin as teacher.  I took the opportunity to introduce the first version to the participants.
 
Uncle Bob and the TDD Tetrahedron.

Guess what. Toyota uses the waterfall method for software development – and now they’re trying to figure out how to go Lean.

Surprised? So was I!

Read on…

I am planning an introductory course on TDD. In that process I have been thinking about how to convey the productivity gain with TDD.

Being a visual person, I had an idea that would illustrate this in a few pictures. Here they are for your scrutiny and enjoyment!

Superstition is a bad thing. At least that’s what I have always believed, regarding myself as totally devoid of the stuff. I mean, me, Mats Henricson, superstitious? No way! But superstition grows out of ignorance, and that’s a valley I must admit I have walked in. And some time ago it struck me that I

My paper about Agile Support has been translated to French.

On March 4-5 Tom & Mary Poppendieck will once again come to Stockholm and teach a lean course with me. "Leading Lean Software Development" is aimed at leaders in organisations that are serious about succeeding with Lean software development. There are still a few spots left, more info and registration here: http://www.crisp.se/leadinglean Join us!

As a part of this weeks Kanban Applied course, the teams had to solve problems using Lego robots.

It was good fun. So fun teams almost forgot about Kanban 🙂

Programming the bot:

A year ago I held an Open Space at Scrum Gathering in Stockholm about Agile Support. I have since received several requests to expand on the topic, so here it comes. Download the article about Agile support with Kanban Good Luck! /Tomas

Are you looking for some concrete expression for Test Driven Development? Let me give you a glimpse of what I am working currently on – the TDD Tetrahedron.

The idea originates from when a colleague at Crisp, David Barnholdt, wrote about not focusing on one step at the time. So I thought for a while and came up with this idea, a tetrahedron where each side displayed “failing test”, “implementation” and “refactor”, respectively.

You turn it and look at the first side where you read “failing test”. You write a failing test and turn it again, reading “implementation”. Write the implementation and run the test to get the green bar. Once again you turn the tetrahedron and read “refactor”. You look for something to refactor, confident that if you do, you will be supported by unit tests all the way.

Or the thing just sit on your table to tell everyone how cool you are as being a TDD programmer. At least wish to be. 🙂

Anyways, here are some sneak preview pictures of the greatest thing that ever happened to the world of programming, ta da – the TDD Tetrahedron!

If you coach a scrum team but you’re not around to observe them during the sprint, how do you know how they felt about it?

Use Emo-lines

I’m happy to say that my Scrum Checklist has been translated to several languages: Russian (thanks Alexander Plutalov) Japanese (thanks Yasunobu Kawaguchi) German (thanks Marc Bless) Portuguese (thanks Demetrius Nunes)

Here are the slides from my breakfast seminar "Agile – ett verktyg inte ett mål" (= "Agile – a tool, not a goal"), hosted by DSDM Consortium. The presentation was in Swedish but the slides are in English. This is more or less the same presentation as my keynote at Integration Agile 2009 conference in

I was interviewed by Mitch Pronschinske on Agile Zone, this turned into two articles: Kanban isn’t better than Scrum, it’s just smaller Scrum and XP are new – their principles are not I think Mitch did a good job of turning the interview into coherent articles (not an easy job). 

Doing a road map can be a tricky thing. There are plenty of constraints and dependencies to consider: how to we balance long and short term improvements? how do we rate future revenue opportunities for our clients? how well do the separate steps tie together to a coherent product? is this fun and challenging? are we keeping our team motivated? can we stop half way?

I find that pair programming is by far the fastest way of traversing the decision tree. Basically, if you are a Product Owner, construct the road map together with another person. Lay out the plan that best meets the constraints and business goals and let the other question the options. (Of course, don’t forget to switch).

Altogether, it helps you check  the different options and prepare arguments. You will be better prepared when meeting the stakeholders. For when you do, there is always something uncertain waiting for you.