Crisp's BlogPage 29

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

Here’s a really short and simple kanban intro: Translations: Brazilian Portuguese Chinese Czech French German Japanese Korean Turkish

Here are the slides from my keynote at Integrating Agile 2009, Amsterdam. First three slides are below, the rest are in the PDF document. Take-away points: Know your goal Agile is a tool, not a goal Tools don’t fail or succeed. People do. There is no such thing as a good or bad tool. Only

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?

Four years ago I spent a few months assembling a rather wide-spread document which I named "State of the art in Server Side Java". It was at the time well researched enough to end up as an entry on The Server Side. Soon thereafter I got sidetracked to follow Ajax for a few years. I

I once worked in a rather large project, about 1000 persons. There are many stories about that project but the one that I’m thinking of now is that we loved to say "stable interface, we must have stable interfaces".

Now, stable means not changing which means nothing gets better. So why would anyone want stable interfaces? And what should we say about the opposite, "unstable"?

Stable interfaces is a cornerstone in tactics for modifiability, so how do stability and modifiability go hand in hand?

Do you see my finger?

Eclipse trashed some code for me today and I had to recreate the workspace. On such days, I can get a bit edgy and maybe I was, when commenting Richard Kronfält’s blog on Scrum and traditional QA.

Sorry about that, Richard, but you are a viking so I guess I can get away with a glass of mjöd if I ever bump into you.

But my point is still, requirements specification is waste. It follows from that the issue tracking is as well. Well, not always.

Here are the slides for my presentation Kanban vs Scrum. I’m glad people enjoyed it! The participants were asked to rate how valuable the presentation was on a scale 1-3. The average rating was 3.0 at Deep Lean and 2.9 at Future of Agile :o) This presentation is based on my Kanban vs Scrum article,

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 🙂

At our last Crisp conference we were discussing different types consulting engagements, and someone (Olle Hallin I think) came up with a useful metaphor – Seals and Albatrosses! Recently we added Ducks and Anglerfishes as well! Seal consulting Some of us are Seal consultants. A Seal is faithful and dedicated to one single client pretty

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.

Your unit test should have no dependencies on anything external, you know that already. So you try not to read any files or connect to a database server.  But what about time? Recently we had some unit tests that failed during nightly build due to daylight saving. Suddenly the distance between two days was 23 hours.

But it doesn’t stop at unit tests. System tests, too, may depend on time.

You should have a strategy for how your system perceive time. Read on.

Are you interested in Lean software development and how this relates to Agile methods such as Scrum and XP? Would you like to meet Mary Poppendieck (leading pioneer of Lean Software Development) and Jeff Sutherland (creator of Scrum)? Deep Lean on May 18-19 is your chance to go beyond the basics, to meet and interact

As you can read in the Crisp blog, some of us have been travelling to Japan to”Find the roots of lean”.
The experiences are many and I will try to write about them in coming blogs but here I will reveal what was the most

important experience for me.

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.

As I mentioned in a previous post, I am right now in Japan with 4 colleagues from Crisp, a few consultants from BestBrains in Denmark, Mary & Tom Poppendieck, Gabrielle Benefield, and some other Lean & Agile enthusiasts. We are visiting Toyota and other interesting companies. It is especially interesting to look behind the scenes

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.

One of the recurring themes on Jerry Weinberg’s PSL course (Problem Solving Leadership) was "There are no hard problems, just hard solutions". Often a problem seems hard only because we make it hard, by attempting a hard solution. When we instead open our minds and find the simple solution, the problem suddenly proves to be

Next week I’m going on a "Lean Study Tour" together with a few consultants from BestBrains, some colleagues from Crisp, Tom and Mary Poppendieck, and some other lean enthusiasts. We’re going to visit Toyota and some other interesting companies.

A couple of weeks earlier I was at QCon Beijing and QCon Tokyo, so I’ve had a week of vacation in between. I’ve spent a few of those days with my family at Tokyo Disney Resort (= Disneyland + Disney Sea), really fun! In fact, Disney Sea in particular is now on my PlacesYouMustVisitBeforeYouDieOrYourLifeHasBeenInVain list, together with Rome and the Grand Canyon.

Anyway to the point…

Being an Agile & Lean coach, I can’t help but notice how things are organized – and I’m impressed! Tokyo Disney Resort is Lean!

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!

På Artima har en mycket intressant diskussion brutit ut under rubriken "Getting Dynamic Productivity in a Static Language". Bill Venners, Martin Odersky (skaparen av Scala), den ibland obegripligt teoretiske James Iry, min favorit i blogosfären Cederic Beust och ett flertal andra brottas igenom långa intressanta diskussioner om statisk och dynamisk typning, "structural typing", klasser versus