1.2 Agile ⇔ Waterfall, or I didn’t mean it that way

agliesoftwaredevelopmentWhen I started to study computer science in 1990, I learnt about some antiquated methods for systems analysis and design (like SADT and HIPO) and the waterfall model. Those methods never felt right.

However, I saw some value in analysis and design and read books like Object-Oriented Modeling and Design by Rumbaugh et al. That all was well before the Gang of Four wrote the Design Patterns book.

A few years later, in 1999, I saw Kent Beck speak at the European Software Engineering Conference about his approach to developing software. Many software engineering professors in the audience shook their heads, but I still remember a few things he said:

  • You don’t have to know everything, but you have to learn faster than others.
  • If you identify something that works, do more of it. If you think of that something as a knob that you can turn from 0 to 10, turn it to 10. If you find 12 such knobs, turn all of them to ten. If you practice 12 great practices intensely, that may feel extreme, hence the name “Extreme Programming”.

That resonated with me. That felt right, after all.

When I joined that large consulting company with a three letter acronym in 2000, I introduced XP and TDD (test-driven development) to my teams. I followed some Yahoo groups and exchanged my experiences and ideas with several of those leading guys who signed the Agile Manifesto in 2001 (I signed it in May 2003).

I practiced Distributed Agile with my teams – a few developers in Austria, some more in India.

I took my ScrumMaster class with Ken Schwaber in April 2004.

In 2005, I gave a talk about Lean Software Development at the JAOO conference in Aarhus where I also met Mary and Tom Poppendieck (authors of those books on Lean Software Development).

By that time, I was considered an expert in in the field of agile and lean software development. I could not understand how people could still follow the waterfall process which was traced back to Winston Royce. I could not understand how someone could have invented something that could not possibly work.

Then I heard the following story in a telephone conference at my former employer by Walker Royce, son of the inventor of the waterfall process: “Behind his desk, my father had a large badge on the wall with the sentence: I didn’t mean it that way.” He said that it felt like an original sin to his father that he had triggered what was to become the waterfall model.

If you take your time to check the original waterfall paper and if you read until page 7, you will see the headline “Step 3: Do it twice” with the sentence:

“If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operation areas are concerned.”

It was fully clear to Winston Royce that software development is not just for code monkeys but full of creativity and learning. That sounds not so outdated anymore.

He was just greatly misunderstood by people who didn’t have any idea about software development and who turned his original ideas into a Department of Defence standard.

If you didn’t know, there’s a long history of Iterative and Incremental Development summarized nicely by Craig Larman. Even software for Project Mercury (to get people to the moon) was developed in very short, timeboxed iterations in 1957, again with a quote from Walker Royce: “He [= his father, Winston Royce] was always a proponent of iterative, incremental, evolutionary development.”

The software industry seems to be field that develops so quickly, still – if you look back – many of the now proven ways have been there for decades. While many former best practices have been forgotten. We keep re-inventing the wheel.

Waterfall thinking, relying some more on upfront work, sticking slightly too long to early plans, is one of the persistent problems in our minds that keep us from getting ahead faster.
Let’s get rid of those handcuffs.

Vorheriger Beitrag
1.1 Finding the Name in Self-Defense against Burnout and Suicide
Nächster Beitrag
1.3 Four Tests To Grow as an Agile Software Developer

Related Posts

No results found

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.
Sie müssen den Bedingungen zustimmen, um fortzufahren


Lust mehr zu erfahren?

Hier registrieren und gratis das Catalysts Handbook bekommen!