Mattias Skarin

At a customers site, teams have been using Scrum for year or more (even the sales people run it 🙂 Developers are talented and motivated. In one team, increased visibility was needed, so I helped them convert to Kanban.

A second team took noticed on what went on, copied the Kanban board and started using it on their own.
 
So before, their sprint burndowns looked like this:
(atleast for the last three sprints)

  Now this is a picture of the same team after two weeks of Kanban

Isn’t it a bit cool? 🙂

There are two patterns that I find linked:

• "I am constantly busy, I don’t have time to think!"
• "There are no new ideas. We just keep doing the same old thing."

It is important to understand how our brain does problem solving. It has an active part, thinking. Then there is a background process, solving in new angles.

Have you ever found a new idea pop up while you are in the shower, when dreaming or when walking to the coffee machine? That is your background process in work.  If you want do develop new cool stuff, or find smarter solutions to problems, you need to make room for that process.

Sometimes I work in projects where team uses sprints, but deliverables are compiled over multiple sprints. In these cases, I have found it handy to do simple Release / Project burndown tracking. It helps facilitate a discussion with client and project stakeholders.

So, here is a template I use. It has the feature of  "dropping" the baseline when additions to the projects are made, showing the net effect of things discovered along the road.

It can be used by a Kanban team, Scrum team, well – any team 🙂

Project and Release Burndown Template.xlxs
Project and Release Burndown Template.xls

I use this in my own head when I visit a sprint planning. So why not share it 🙂

• Do all team members understand the meaning of the story?
• Is the definition of done clear?
• Do all team members understand how the solution intends to solve the problem?
• Is the story broken down to a level so that team can cooperate around solving it?
• Is there a high cost of failure such, we need do address risk?
• Are stories related to outside parties in such a way this needs to be cared about?
• Is there a last responsible moment at which we can’t roll back?

Experience the humbleness and energy of so many people in one single place was a great experience. I would have liked to stay longer just do discuss and share experiences.

Takeaways:

• As Agile practitioners, we need to continue to evolve
• Kanban is a promising tool for sharing Lean benefits outside teams
• Pick the right tools for the job! Kanban and Scrum have their advantages, start with your problem and then pick the right tool
• David shared my experiences with Kanban teams demonstrating a "white box" behaviour instead of a "black box" (not your business) towards its stakeholders
• Classes of Service is a hot upcoming topic around Risk Management
• In Japan the "why" is the most important thing. Therefore rigorous effort is spent on understanding Values and Princinples, compared to our Western approach of staring with the Practices (therefore not being able to adopt when situation change)

Enough chat. Here are the slides:

• Future of Agile – David Anderson
  http://www.crisp.se/futureofagile/slides/davidanderson

• Kanban vs. Scrum – Henrik Kniberg
  http://www.crisp.se/futureofagile/slides/henrikkniberg
  
  
• Roots of Lean, visiting Toyota – Mattias Skarin
  http://www.crisp.se/futureofagile/slides/mattisskarin

Have a look inside the mythical Crisp software factory. Discover the secret of how we really build software 😮

Inside Crisp Software Factory.avi

In a famous Leadership IQ study, we surveyed 48,012 CEOs, Managers & Employees about their performance appraisals. Here’s the shocking results: Only 13% of Managers & Employees thought their performance appraisals were effective. And only 6% of CEOs thought their appraisals were effective. We also discovered that only 14% of employees say their performance appraisal conversation offered meaningful and relevant feedback.

So are we
 a) continuously allowing people work on what they like to do, with minimum overhead, or
 b) adding makeup to broken processes

Read Esther Derbys excellent followup

I held a seminar at NFI today "Introduction to Lean Software Development".  Afterwards, I got the question "where is a good starting point to learn more?" – and realized that while there is new material, much is still "in work" (for example: Mary and David are both working in new books).  So updated information it is not easily found.

If you are completely new to the subject:

• Implementing Lean Software Development – Mary & Tom Poppendieck
  [comment] While there is newer material, this is a good starting point.

"I have the basic understanding and now want to move on to the software specific stuff"

• David Anderson Kanban for software presentation
  [comment] good visualization of concepts in practice

• Mary has a great essay page
  [comment] nice inspiration

• ..or grab my slides from today  "Introduction to Lean software development"
  [comment] ..note, at least half of the content was delivered verbally, but the stuff in here is up to date

Psst!: Two great opportunities exists in May to get the latest in Lean here in Sweden:

• Deep Lean 18-19 May –  with Mary Poppendieck and Jeff Sutherland
• Future of Agile – with David Anderson, Mattias Skarin and Henrik Kniberg

I attended the Lean & Kanban conference last week. The first of it’s kind, a big boost of energy and I certainly hope to see more on this subject.

It was striking how, in case after case, the simple introduction of visual management and matching work to capacity (Kanban) sent teams off on a journey exploring Queues, Pull, System Thinking and even Deming(!). 

Here are my biggest takeaways:

• Even highly performing senior teams get a boost by using Kanban (a bit of surprice to me)
• Classes of service enables teams to self organize around risk elimination. (David Anderson). If you have been thinking of  "is there any way around analysing full test suite/architecture up front – this is what you are looking for. Extremely interesting stuff.
• It was nice to hear the community has picked up that the primary model for software is Lean Product development first, then ideas from lean manufacturing
• How system thinking quickly was perceived as the primary constraint when scaling and how Deming holds many answers
• Talking to Dean Leffingwell an confirming my thoughts regarding the need for a cooperation model

I ‘ll probably come back more on this subject 🙂

When applying Lean, or thinking about scaling agile benefits to the Enterprise we tend to "home in" on the practices (Release cadance, Kanban, Flow, Portfolio management, risk etc). These are all valuable and the world would be a happier place if used more 🙂 . But – it is as important to not to forget to bundle those practices with a cooperation model.

Basically, practices without a cooperation model = high risk of failure.

I have updated the original quick reference originally created for system administration teams now to focus on introducing Kanban. A two page A4 visual of "what is it all about".

So here is Kanban in 5 min.

Back from Japan! It was a very learning week. Among other we met

• Manager for Toyota automotive  software
• CEO of Fujitsu Siemens Software
• Representatives from the Agile community in Japan
• Agile pioneers such as Eiwa and Azzuri
• Cheif engineer of Lexus and Supra program, Katyama-san
• Former IT manager of Toyota Kuriowa-san

And of course visited a Toyota plant 🙂

It was really interesting to see:

• Toyota’s response to the current crises, totally different from what I’d expect western companies to do
• How continuous improvement, Kaizen, is on top of the agenda. Especially CEO’s. "It is in our DNA"
• How Kanban is the center of the modern Japanese software shop
• How the Agile community of Japan is spearheading changes
• How new cars got developed and how people leading these efforts where picked (comparison: Product Owner in Scrum)

I am going to talk more about this in my session at Future of Agile.
Big thanks to Bent and Kenji who made this possible.

I am currently on a visit to Japan to meet Toyota and representatives from Japan’s industry to learn about their challenges. Already on day one, things got really interesting.

We met today with the CEO of a Fujitsu subsidiary, specialized in software. The company is applying TPS to improve their practices. It was interesting to see that:

• The CEO was puts improving engineering and kaizen practices on top of his agenda. He is committed and actively involved, driving improvements. In his world improvements comes first, operations second.
• A sign of the ambition is the fact that the company employs a mathematical expert to help out with analysis. When would that happen in a western company 🙂
• They are experimenting a lot with estimation techniques! The technique currently favored is "Function Scale" –  a simplified version of Function Points. The technique is based on user interface design and is fast, only takes 1-2 minute compared to what a skilled function point analysis would take 30 min or more to do.

Some reflections:

• Culture and local experiences affects solutions looked at. Turning to TPS, Kaizen and statistical process techniques for improving software products is therefore logical
• But – using best practices based on other’s success, without thinking (what problem it was intended to solve, how this would help our situation) – is dangerous. Not only can this stop you from solving the right problem (you might be in another situation!) it can also dilute your competitiveness no longer staying ahead. Something to think about when we apply Scrum, Lean or any practice.

Anyway, a really interesting week up ahead! Tomorrow, first visit at Toyota plant, later in week , meeting the former Lexus cheif engineer Kataymy-san and the former IT manager of Toyota.

The schedule is taking shape for May 27:th,  we now announce two more sessions:

• Kanban vs. Scrum – Henrik Kniberg
• Roots of Lean and Agile  – direct report from Toyota visit

Also, meet the experts face2face in the afternoon open space session. Here is your chance to discuss in person with the father of Kanban, David Anderson and with Henrik Kniberg.

More is to come. Seats are limited. Don’t miss out.

http://www.crisp.se/futureofagile

In the 2:nd of April I held a talk for the danish public sector at the ISA conference in Aarhus called  "Agile – Myth or Magic?"

The slides are avaliable here

It was interesting to meet many from the public sector and discuss their challenges. The Danish Ministry of Technology and Development has come a far way in Agile Contracting. I hope to see more reports from this!

When running Scrum (or Kanban), you will need management involvement. And it is actually better that you secure it from the start.

Don’t get me wrong – I am not advocating  detailed control and interference. No, what I am talking about is getting some punch behind dealing with impediments that your team will surface.

When I have worked with scaling Scrum over several teams (up to 10 in parallell), I have strived to strengthen the same processes that gives traction to a single team.

Alistair Cockburn compiles this beautifully in his Software engineering in 21:st century

People issues determining a projects speed

• Can they easily detect something needs attention? (Good at Looking Around)
• Will they care enough to do something about it? (Pride-in-work; Amicability)
• Can they effectively pass along the information?  (Proximity; face-to-face)

For all you heroes fighting a daily battles convincing teams, managers, tester, that deploying  software work to production anytime using CI it’s possible, well here is a story that might encourage you. (Thanks to Xavier Allue).

In the 1950’s, a japanese team struggled with a big die press. The die press could not be changed to new conditions fast enough, so they always had to work with big batches in order to make up for lost setup time.  (big software project ring a bell?). The team decided to get that setup time down from double digit to single digit number. It took them years. But – they actually finally made it.

At the time, there was an alternative point of view:

"While these japanese guys like to promote the notion of fast setup
changes, this simply isn’t viable on very large scale activities. For
example, this die press here next to me uses 3-ton dies and takes five
foremen a full day to configure…"

Before we consider agile contracting, or projects in general – there is one thing we must start to be honest about.

We cannot estimate a software problem accurately. In fact, our best estimate will most likely have a variance of at least 100 percent.  There is a reason why people like Alistair Cockburn calls this "the unsolved problem in software development.

• An upfront estimate replacing a 15 year old system I did with a team turned out to have a scope difference of over 100% in the end. To our help we had really skilled Business people with us all the way. (..we met the deadline and customer was excited but that’s an Agile story).
• Typically the scope ends at 189% of original estimate. (The Standish Group’s chaos report).
• Big upfront design results in over 45% of functionality never used (Scott Ambler , Dr Dobbs journal)
• There is a 10 to 1 productivity ratio between developers. So who does the job has a profound inpact (Software Cost Estimation with Cocomo II)

Alexey Kritivitsky (Ukraine Agile community) has created a fun Scrum training exercise new teams using Lego.

Since games is such a brilliant teaching tool, you should know about it 🙂
http://tinyurl.com/legoscrum

6 months after we began using Kanban to two support / system administration teams they realized that the downside of having multiple projects running outweighed the possible upside.

How long time should there be between goals?

Some make a habit of setting yearly goals. Some set quarterly. Small organisations in a turmoil can set weekly goals.

But what is "just right"?

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.

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.

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

I today got these sent from my collegue Hans Brattberg. It it an essentional vocabulary for the Agile practitioner 🙂

* BLAMESTORMING.
Sitting round in a group, discussing why a deadline was missed or a project failed, and who was responsible

* SEAGULL MANAGER.
A manager who flies in, makes a lot of noise, craps on everything, and then leaves

Alistair has kindly published a summary of ideas and practices around Agile contracting,
Areas covered, Fixed time, Fixed Scope and some new ideas.

But remember, in any contract honour the Principle of fair exchange (by Verna Allee):

"Do not enter a contract where you would not wan’t to participate as either side as signing party."