På ett bräde blev boken Riv pyramiderna igen dubbelt så tjock (222 sidor) med det nya kapitlet “En organisation utan huvud – en agil odyssé“. I den gör vi en historisk, praktiskt och teoretisk resa från apache-indianerna, över Ford, Toyota, Lean, Scrum, Agile, flödeseffektivitet, Hegel, Kant, hur det påverkade oss och mycket mer. Slutstation:en massiv

Here’s the eBook collecting my articles on building the quality in by stoping the line: Stop The Line – Why it’s crucial to include a human touch to your automated processes

If you don’t dare to stop the line, continuous integration might be waste. Here is the second part of my three-part series on building the quality in on the SmartBear blog. In the first post of this series, I wrote about Toyoda Sakichi, the founder of the Toyota industries, who invented a loom that would

We in the software industry are still far behind when it comes to automated quality checks. Toyoda Sakichi for example invented the automated loom with stop the line capability almost 100 years ago. I write more about that in my first blog in a three-part series on building the quality in on the SmartBear blog.

Continuous improvement is a central part of both agile and lean; it’s the way to increase the productivity and ensure that the organization delivers an ever increasing level of value to the customers and the organization. Lean is derived from Toyota and the Toyota Way, which has inspired a lot of companies in the western world in their quest to increase their productivity as well. But we often focuse on the techniques and practices and do not see the more fundamental parts of the Toyota system that enable their very high level of improvement each year.

I worked at a company that tried to implement the Toyota Way and reach the same level of continuous improvment with what I believe to be the wrong focus. My company estblished a goal to reach seven improvements per employee in average per year. A goal that was inspired from a report that stated that Toyota implemented 1,000,000 improvements per year, which of course, is very high. This is one of many aspects that show why Toyota has managed to grow they way they have done during the last 50 years.

Continue reading

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…

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.

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 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.