EppsNet Archive: Iterative Development

Risk = Cumulative Cost – Cumulative Value

9 Mar 2014 /

Henrik Kniberg has a presentation online called “What is Agile?” It includes a method of visualizing risk as the gap between cumulative cost and cumulative value, as well as methods of visualizing risk mitigation strategies.

I found it valuable. Here are some representative slides:

Big Bang = Big Risk

Agile = Iterative + Incremental

Improving the Value Curve


Customer Engagement

24 Oct 2010 /
Book cover

You want to actively elicit feedback from end users using short development cycles or by using prototypes and models during analysis. A good feedback cycle has the appearance of causing problems. It will cause emergent and latent requirements to surface. That means rework: the value of prototypes is that they push this rework back into analysis, where it has more value. And most important, good end user engagement changes end user expectations. It is only by participating in a feedback loop that’s grounded in reality that customers get the opportunity they need to reflect on what they’re asking for. If your customer changes their expectations in the process, you’ve both learned something. Embracing change doesn’t just mean reacting to it: it means providing the catalysts that accelerate it.

— James O. Coplien and Gertrud Bjørnvig, Lean Architecture for Agile Software Development

Why Don’t You Go Ahead and Do Something?

4 Feb 2009 /

We place the highest value on actual implementation and taking action. There are many things one doesn’t understand and therefore, we ask them why don’t you just go ahead and take action; try to do something? You realize how little you know and you face your own failures and you simply can correct those failures and redo it again and at the second trial you realize another mistake or another thing you didn’t like so you can redo it once again. So by constant improvement, or, should I say, the improvement based upon action, one can rise to the higher level of practice and knowledge.

— Fujio Cho, President, Toyota Motor Corporation, 2002

Guarantees vs. Commitments

8 Mar 2008 /

A thought exercise: “How long will it take you to get to work tomorrow? Can you guarantee it? To give us a guarantee, you’d probably put a buffer on your answer first. I guarantee a team working to put together software for the next two weeks is engaged in something a lot less well understood than a daily commute. We can put in a buffer – promise less – to give you a guarantee, or we can work from our estimates and do our best.”


Declaration of Interdependence

24 Dec 2007 /
  • We increase return on investment by making continuous flow of value our focus.
  • We deliver reliable results by engaging customers in frequent interactions and shared ownership.
  • We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
  • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • We boost performance through group accountability for results and shared responsibility for team effectiveness.
  • We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Respect the Classics, Man: No Silver Bullet

28 Jun 2006 /

This essay by Turing Award-winner Fred Brooks is almost 20 years old now. Sadly, the ideas on incremental development are still considered outside the mainstream in IT, which continues to favor the widely-discredited waterfall approach.

Continue reading Respect the Classics, Man: No Silver Bullet


The Waterfall Approach Persists as an Urban Myth

7 May 2005 /

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.

We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural . . .

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description did for us was make us realize that we were doing something else, something unnamed except for “software development.”

— Gerald M. Weinberg

In his book, Agile and Iterative Development, [Craig] Larman has well documented the history of the many disasters introduced by accident when the Department of Defense standardized on a non-iterative method that was unproven on large projects. It was essentially a blunder by a consultant who had little experience with real software development.

The DOD has long since abandoned the waterfall method, and the consultant has recanted, but the waterfall approach persists as an urban myth in many software development organizations.

— Jeff Sutherland