Why the Toyota Product Development System is a thing of the past

This post tries to explain why website/app development is Production and should use the Toyota Production System (TPS) and why classic software application development is product development and can use the Toyota Product Development System (TPDS).

Overloading QA
Creative Commons License photo credit: drewgstephens

Recently there has been a conundrum in parts of the agile and lean community: Obviously the Toyota Product Development System (TPDS) and software development uses a waterfall (or similar spiral) process:

What might surprise some, was that they were using a waterfall model (in Ishii-san's own words - in reality I think it was more like the spiral model). In spite of that, I had a feeling afterwards that I had just talked to perhaps the most skilled software development managers I have ever met! Does that sound like a paradox? I do not think so.

Toyota today looks so much like a religion that people are willing to suddenly proclaim "waterfall" is a good thing if it's done by Toyota:

I once said to myself that I did not want to waste my time as a developer on non-agile projects. In the Toyota case, I would certainly make an exception "Toyota is using waterfall!"

Or even, from Mary Poppendieck,

When you are dealing with embedded software in production hardware, a 3 month waterfall is really fast.

And as Sean tries to explain in his comment on another post:

If the projects that Toyota is working on span only a couple of weeks, then waterfall is probably going to work fine. They'll only develop requirements for a few weeks worth of work, and their in-process code inventory will still be pretty small.

So why should we use TPS and lean in software development, when Toyota does Waterfall and TPDS? We're confused. But remain calm. There is no conundrum. If you have clear requirements, a limited project, a fixed feature set and a fixed deadline, use waterfall. This is what Toyota probably experiences. Most people in the agile community will tell you it's only best to use agile and go lean when you have unclear or changing requirements, changing feature priorities and work in a flow model instead of a project.

After reading the Toyota Way book, and twittering about TPS, I got the following reply:

@flowchainsensei: "Might like to take a look at TPDS too (more direct relevance to software development) Kennedy, Ward, etc."

So TPS/lean isn't for software development? After some more thinking, whether software development is more like Toyota Product Development (TPDS) or more like production (TPS), I had an insight. For your web app development there are 2 phases:

Phase 1: Version 1.0 done with product development (PD)
Phase 2: After that companies shift to a production (P) model

Note: You should keep the PD phase as short as possible.

Websites and web applications are different than your usual software application development. Website/app development has many more direct stakeholders: Reporting, Controlling, Marketing, Sales, Product Development, Customer Support, Backend Services and more. Contrary to classic software apps, they all have direct involvement into features. In webSite/app development, those stakeholders write their own (!) stories and directly contribute features. On the other hand in software app development, features are mainly developed by a product development department with indirect input from other deparments.

Therefore software app development is much more product development (PD) heavy, while website/app development is much more production (P) heavy. With more direct involvement, smaller stories and changing requirements, more and more development will move into production style in the future.

The same will happen inside Toyota. My prediction: Over time at Toyota TPDS and TPS will merge, when every car is build-to-order, with it's own design, with custom colors, each with a one-in-a-kind motor etc.

This is what Scrum tries to accomplish, merging production and product development. An enviroment in which web companies are already. Each story to be developed is the same - consisting of web forms, services, database code, reporting etc., but at the same time every story is different. Think of stories as being all the same, e.g. web-service-db stories, but highly customized and build-to-order for each customer (marketing, product development, sales). Then it becomes clear that development in web companies is production, not product development.

This merging is also the area where Scrum struggles: How to put design, architecture work, technical debt etc into development, and Scrum still hasn't settled for the one best practice.

Hope this helps clear up the "Conundrum", which isn't one.

New Version of my Simple Kanban Board Application

Over the weekend I've worked on my Simple-Kanban application. Simple Kanban is a small Kanban board application in one Html file. New features are a data mode that displays the data in raw format for easier cut & paste and drag & drop support for moving stories around.

Simple Kanban Screenshot

There is a website now! I've added a small website at http://www.simple-kanban.com, where you can find new versions. I've also created a GitHub repository for Simple Kanban, where I'm planning to post the code (funny, the code is already open source as part of the Html file 🙂

Much fun with using Simple-Kanban in your company, think lean!

Micro Book Review: Agile Retrospectives, making good teams great

Title: Agile Retrospectives, making good teams great
Author: Esther Derby / Diana Larsen
Pages: 165

What the book is about
The book is about leading retrospectives. Retrospectives came into fashion with agile software development, especially Scrum has retrospectives every sprint. The beginning of the book motivates retrospectives, explains them, shows how to lead them and establishes the concept of phases: set the stage, gather data, generate insights, decide what to do, close the retrospective. The second part explains detailed several activities you can use in each phase. A description is structured like the famous design pattern book: Purpose, Time needed, Description, Steps, Materials and Preperation and Examples.

What I've learned from the book

  • Retrospectives have several phases: set the stage, gather data, generate insights, decide what to do, close the retrospective
  • There are many activities for retrospectives, you should change activities from time to time
  • Use an activity like"appraisals" for closing a retrospective

Should you buy this book?
Yes, highly recommended

Who should buy the book

  • Every ScrumMaster or Iteration Manager
  • Everyone who leads retrospectives

Book bought by myself due to a mentioning on Twitter.

I've chosen the micro review format because it lends itself to be used as a future micro format and I like short reviews myself. You can read the table of contents elsewhere, I don't like it when reviews iterate the content.

Kanban Board Application in One Html File

For some years I've been interested in lean software development and how to reduce waste. While introducing lean practices, I've needed a small, simple Kanban Board application. Thought I'd write one.

You can download a very first alpha here or see it in action here.

Suprised? The application is just one HTML file, no installation needed, no Java, Ruby or PHP. One HTML file, no other dependencies.

How to use the application?

Edit the source of the HTML file with an editor of your choice, preferably one which knows HTML. You will find a list of stories. The example contains those:

T_Q,S18,Checkout optimize
DE,S2,Build old shop
DE,S4,Rebuild with SOAP
DE_Q,S10,Rebuild with REST
P,S17,Do something with OpenID
D,S3,Make application faster
D_Q,S7,Credit Card Payment
DE,S13,Build something astonishing
P_Q,S17,Fix YSlow
R,S39,Google Page Speed fix

There are three columns for stories. The first column contains the state the story is in, the second contains an identifier for your story and the last column the name of the story. You can edit the columns, change states, change names, remove and add stories. You can also export form Excel to csv, then cut&paste into the application source.

The available states are described next in the file:


They need to be available for the stories and match the states of the stories. You can add, remove or change states. Every state has a "sub-state" as a ready queue. For example the ready queue state for Design "D" is "D_Q", for Test "T" it is "T_Q". You do not need to describe the ready states, they are automatically created and a ready queue is shown in front of every state. For example "Test Ready" is shown left to "Test", if there are stories in that particular state.

Customize the colors

The colors of each state are defined in a CSS block.

.box_P { background-color: #FFFF00  ; color: #000000;}
.box_P_Q { background-color: #F0F0F0; color: #606060;}

Feel free to change them to your taste. ".box_P" is for the "P" state box, ".box_P_Q" for the corresponding ready queue.

The main use case for this application is to inform a company about the stories which are in development and in which state they are. It's an ideal information radiator. I plan to use it on a huge screen.

I'm thinking about a CouchDB storage implementation for storing data and application logic. Or storing data in the file, with drag and drop, inlining Jquery, editing and storing like TiddlyWiki does.

Future features? Add WIP limits, add "From here" signs to display cycle time until live.

Have fun with this One-File-HTML-application. Tip: you can easily mail it around, no install needed.