768R: [scrumdevelopment] Waterfall and Dr. Winston Royce
- Dec 14, 2002Mary,thank you for this great post. You are able to put new lights upon things.
Da: Mary Poppendieck [mailto:mary@...]
Inviato: venerdì 13 dicembre 2002 4.50
Oggetto: RE: [scrumdevelopment] Waterfall and Dr. Winston Royce
Although I agree that Winston Royce’s paper doesn’t describe an Agile process of today, I think it is not such a bad paper if you take into consideration the following:
1. In figure 7, Royce proposes an early ‘simulation’ done by a small skilled team, to prove the concept. Thus he says that a complete iteration through, testing and usage, is the most appropriate form of feedback. He notes that going only one level up is not adequate.
2. I certainly disagree with Royce on the usefulness of the extensive documentation he recommends. But note – you can substitute tests for most of Royce’s documentation, and if you do this, the paper is not so bad. Royce didn’t have access to the testing capability we do today, but if he did, I’ll bet most of his documentation would be changed tests in a 2003 paper.
3. At least Royce admits that everything besides analysis and coding is waste. How many people have been insulted when I called all that other stuff waste! Now I can quote Royce at them and have someone with real credibility back me up.
I have a suggestion that comes from product development. In the 1980’s, product development in the US was decidedly sequential. Nobody had a clue how to do it any other way. You’ve got to excuse the software development writers of the time for their sequential bias – it was everywhere (in this country anyway).
In the late 1980’s, Kim Clark studied the product development practices of automakers world-wide. The results are in his book “Product Development Performance” (1991) and Womack’s book “The Machine that Changed the World,” (1990). They noted that Japanese product development practices saved 1/3 in development time and 1/2 the development effort, and resulted in better products – consistently, across the industry. They called Japanese practices concurrent development. Most US automobile companies have moved from sequential to concurrent product development, as have many other companies.
Clark points out that the fundamental difference between sequential and concurrent development is the information flow between people. It is high bandwidth, bi-directional, and concurrent (ie, information gets transferred as soon as design starts, not when its done). The feedback provided by this approach is enormous, and accounts for the large, consistent improvement in performance.
I vote for a redefinition of terms: Waterfall becomes sequential. Agile becomes concurrent.
Sequential is a true description of what is considered traditional software development, and is not a pejorative. Concurrent captures the essential difference of Agile, especially since it requires broad communication and feedback. (I know you said the heart of agile is creativity, but who’s to say that a sequential process has no creativity?)
- << Previous post in topic Next post in topic >>