I saw this post and could not resist leaving a comment. Here’s what I wrote as a comment to that post:
How can they [Toyota] apply waterfall and be predictive, fast and high-quality? Those are all qualities that waterfall lacks.
Predictability is lost because of lack of visibility into quality until it is too late (the test phase). Not to mention that trying to predict how a software project will go is like playing Lottery blindfolded and selecting a ticket to the wrong draw!
Speed is lost because writing requirements up front leads you to create a lot more requirements than you really need because you don’t have the feedback of running software.
High-quality is lost because waterfall leads to slow and late integration which leads to many defects being left in the software! Not to mention that you can’t inspect quality in, you have to build it in!
Now I’m curious about how you get out of that “they use waterfall but they provide all of the “goodies”!
Oh, and you can’t say “they said they used waterfall but did not actually do that”! 😉
What do you think? Do you agree that Waterfall can be used with predictability, speed and high-quality.
5 thoughts on “Does Toyota really use waterfall for software development?”
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.
Now, we could argue whether 4-week software projects can even be called “waterfall”, since the typical connotation of waterfall is Very Large Projects. But if we pass over that, then, really, what’s the difference between a 4-week waterfall project, and a 4-week agile project?
@Sean There can be huge differences between a 4-week waterfall and a 4 week Agile project (even if the iteration is 4 weeks).
In Agile we don’t spend as much time with the detailed design for example, because we have the belief (corroborated by experiment) that running software is a much faster way to evolve the design. Do some, show it, get feedback, do it again. Even if it is counter-intuitive this method is *much* faster, and delivers high-quality.
There’s a caveat though, even if it is more difficult to fail with Agile it still is very much possible, so the method is not the silver bullet. You still need to use your brain! 😉
@Vasco I fully agree with your second paragraph. However, your first paragraph does not necessarily follow from that.
You assert that there can be huge differences, but provide no supporting argument.
However, I don’t necessarily disagree with your assertion.
@Sean The first paragraph is a statement that I cannot fully back-up in one comment. Maybe I have to start writing a post about that! 🙂 However the second paragraph is an example of how there can indeed be huge differences between a 4 week waterfall and a 4 week iteration in an agile project. That is not, however, the only difference.
Maybe I really should write that post about the differences.
Some clarification from Mary Poppendieck on what “waterfall” means in the context of Toyota.
As expected, it does not mean the same as elsewhere.
Here’s the blog post with the comment from Mary.
Comments are closed.