Why the TPDS 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).
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
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.
