Does Toyota really use waterfall for software development?

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.

Marketing fail redux, the Agile Process edition

I was reading a web-site from a "well know" process person/company in the software field (which will remain unnamed) and found the following quote (names changed to protect the guilty):

XYZ corporation senior management decided that ABC Unified Process is the way for better quality, higher productivity and lower cost.

I can't begin to describe how many ways such a quote makes my back shiver in disgust, but I can't resist to share this one.

In the quote the VP of XYZ corporation is endorsing ABC's unified process, which in ABC's view is a good thing because that's what they sell. However, they forget that it is not "senior management" that makes decisions about what process affects "quality", gives you "productivity and lower cost" and cure cancer, serving coffee and toasts to boot (the ABC's marketing people will have you believe). It is reality and the market out there that decides what processes work!

Look, dear ABC marketing people: senior management are the worst people to decide on what software processes to use! They haven't coded for a whiles (if at all) and are probably a lot more worried about sales, revenues, turnover, etc. They don't know about how the software process helps their workers.

If you want an endorsement for a process go to the Gemba! Ask the people that have to code/test the software products or the tech support staff that has to flee angry mobs when the software craps out on the customer!

Please, please don't push any more senior management endorsement quotes to software development processes. There's a lot more that senior management could endorse like, for example, the best off-shore tax evading finance advisor...

The curious case of buttoned-up Benjamin

Benjamin works in a consulting company where there was no dress-code unless the client would have a dress-code. Since most consultants were testers and coders (and you know how we dress) the clients understood not to demand a formal dress code.

Then Benjamin's company changed his boss. The new boss required and insisted on everyone wearing a suit and tie for any work for any client.

Benjamin heard of the news while on an assignment that he had started 3 months ago. He had a good relationship with the client, the work was progressing at a fast clip and the client was happy to have Benjamin there despite him not wearing a suit and tie.

Benjamin had a conundrum. He could continue to wear his pull-over sweater and t-shirt at the client as he had done for 3 months and risk being denounced to the new boss or go for the suit and tie which he hated because it made him sweat. After much consideration he decided that he would wear the suit but not the tie.

The boss called a meeting with Benjamin and in between all of the spitting and shouting said "you either do as I say or you're back to low level work here at the home office and you will not be in any client project". The boss felt that Benjamin was personally disrespecting him for not wearing a tie at work.

Benjamin, a veteran of IT projects knew that the best way to handle this situation was to let the boss fall flat on his face and decided to retire from the project and inform the client that, he was no longer allowed to be in the project due to the case of the missing tie.

He left the client's project and the boss put another consultant in his place. The new consultant made a mess of the project to the point that the consultancy company had to put a second consultant on the project for no extra charge to the client in order to have the project finished without a much larger delay and possible penalties.

This same company still has not fired Benjamin's boss, in fact they have probably awarded him a bonus for having the decisiveness of instituting a dress code, and Benjamin is still working on back-office projects at HQ instead of doing work at clients.

This is a true story. It is also one of the (many) reasons why I'm glad that I live in a country where people are valued by the work they do and the results they achieve instead of by spurious shows of dictator-like tendencies and the price of their suit and tie.

Benjamin's boss is a person that does not understand software or software people but he has a position where he can boss them around and that's what he does!

If you find yourself in a position like that don't walk away... RUN! Bosses like that should be given only one reward: the pleasure of working alone!

Update: corrected 2 typos.