Crisp's BlogPage 30

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

I Computer Sweden skriver Ivar Jacobson att Det knakar rejält i Scrums fogar och trots att Ivar låter som en gammal sur gubbe som glömt att även RUP genomgått samma hypekurva som Agile/Scrum nu gör håller jag med honom om riskerna på en punkt: Det finns verkligen en tendens till "ingen arkitektur, ingen modellering, bara koda och strukturera om senare".

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

I teach a course on System Architecture. It is a three-day course attended by experienced developers who want to go further in some respect.

What strikes me most is that the majority has never read any architecture document. Since writing such documents is one of the main topics of the course, I have a long road for them as they haven’t read any.

So, when you are faced with a system that you are about to change, how do you go about to understand it?

Niclas Nillson, Factor10, har just publicerat ritningar för sitt parprogrammeringsbord.

Teams often thinks they need to improve on estimating.
I think it is waste to try do that. 
But difference in actual and estimated velocity is good information, and nothing to be sorry about.
Mike Cohn have taught me this through his books "Agile Estimating and Planning" and "User Stories Applied". 
His teaching has been one of the most influental for me.
Find out more at his site: www.mountaingoatsoftware.com

The Wicket framework is somewhat deceptive when it comes to testing, especially TDD.

A German translation of my book Scrum and XP from the Trenches is now available. Thanks Robert Sösemann & Andreas Schliep! Russian, French, Spanish, Japanese, Chinese, and Portuguese translations are also available. Korean, Italian, and Slovak translations are underway. I never cease to be impressed by the agile community! So far, every time I’ve blogged

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)

My collagues are talking a lot about Lean these days. I thought it would be interesting to simulate one of their examples using JavaFX.

Here is a picture:

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)

As an Agile/Scrum coach I value commitment from the team at the top of my requirement or wish lists, even higher than Kaizen (Continuous Improvement).

So why is this so important?

David Barnholdt and I recently attended a 1-week PSL workshop (Problem Solving Leadership) with Jerry Weinberg, Esther Derby, and Johanna Rothman, one of the best courses I’ve ever attended. After that course we’ve been thinking about ways to make our own training courses more interactive. David was first out and invented a brilliant exercise demonstrating

Me and Oscar is currently working on a small project, just to learn JavaFX.

We stumbled on some nasty crashes which we at first did not understand.

ArrayIndexOutOfBoundsException? Is there a bug in JavaFX?

It turned out to be a callback from Java. Let us see how we got there.

Webbramverket Lift, skrivet i Scala, har precis släppts i version 1.0. Mycket spännande, tycker jag. Citat från Michael Galpin: Lift is the only new framework in the last four years to offer fresh and innovative approaches to web development. It’s not just some incremental improvements over the status quo, it redefines the state of the