Scope, Resources and Processes: Change Everything!

As an agile writer, I like to write articles in multiple iterations. Feedback from readers is essential to me. There’s no such thing as gettings things right the first time around. Not for programmers, and not for writers. So I’ve decided to give the readers of this site a chance to be the first to read my latest article.

The article is called Project Change, a Way of Life (PDF, 2.27MB) In this article I try to link complexity science with agile software development. I attempt to show why there is no such thing as a best software development method, why managing scope is a too simplistic interpretation of “embracing change”, why corporate standards for processes are a bad thing, and why you will never get things exactly right.

The article includes comparisons to biology and other types of complex systems, several little nuggets of wisdom, and some personal experiences involving my car. Here’s a little sample of what you can expect…

For biological systems the search across the fitness landscape is not an intelligent one. DNA is mutated in random ways, and species do their adaptive walks in all directions, including every wrong one. But natural selection comes to the rescue by making sure that the individual organisms that happen to have landed (blindly) on a higher position on the fitness landscape are the ones most successful in reproducing themselves. Human-made systems apply a different strategy. We cannot afford to simply try out every combination of features, resources and processes. In our case not natural selection but conscious selection comes to the rescue. Humans have the intellectual capacity to make an educated guess on where the higher peaks are, even though the fitness landscape is an abstract thing. We balance features against qualities, we fire and hire employees, we discard and select tools, and we add and rework the processes in our software projects, hoping (and often expecting) to walk in the right direction, improving the fitness of our systems along the way.

Go ahead! Download the complete article, and tell me what you think!

  • Seven Little Moments of Ecstasy
  • Edward Lorenz (1917 – 2008)
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • Rich McCabe

    Jurgen,
    I gave your draft paper a fast scan–of course it deserves more. But, although interesting, I find your blog entries on complexity usually more to the point–the point being: ok, so software development is a complex system, what do we do about it? Schwaber has been able to use the insight to provide a broad rationale for why Scrum is superior to conventional, non-agile approaches, but are there specific techniques in dealing with complexity that transfer helpfully to software development?
    I am not aware of (m)any. Unfortunately, the key characteristic of non-linear systems is that they are a lot more difficult to deal with than linear systems.
    A few other random comments that occurred to me:
    + I recommend you consider softening your position on organizational standards, and even the CMMI. George Box is attributed with the quote “All models are wrong, but some are useful.” I am a huge agile proponent, but just because uses of the CMMI or process models you find in typical organizations are often ill-considered, that doesn’t mean these concepts are intrinsically harmful. The fact that you believe you’ve been able to “automate” project evaluations contradicts your contention that standards are obsolete–what is the basis of your evaluation technique if not an organizational standard of some sort? We just have to think of these things more broadly rather than be limited to only the (admittedly, prevalent) poor examples.
    + I do not quite buy that interdependence among variables in a complex system levels the performance landscape. Yes, it tends to level it, but that does not preclude the continued existance of optimum spikes. It is just that these spikes are, perhaps in some sense, less frequent, and, intuitively to me, steeper–more spikey. Hence, the tipping point effect.
    + I thought you were going to make the case (but I was not able to find it–perhaps I just missed it) that in a dynamic complex landscape an important survival attribute is the ability to move off of a local optimum point and find and scale other optimum points. An entity that has fully adapted to reach the very top of a particular local optimum may be out of luck the next moment the landscape changes, and its own special optimum point sinks back into the muck. The idea suggests that there is value in being very adaptive, as opposed to being highly optimized for a particular niche.
    But thanks for your views. Keep thinking and writing.
    Rich

  • http://noop.nl Jurgen Appelo

    Rich, thanks a lot for your comments! Some replies:
    – Have you seen my latest post (Crawling to the Tipping Point)? I think it’s a nice example of what complexity science can teach us in software development.
    – I think methods and standards are useful for picking some best practices out of them, and see if they apply to my own situation. I don’t think they are useful as a description of how we should run our software development businesses. No wonder they all claim that they should be “adapted” to the local context. It only proves that they aren’t useable the way they are.
    – About the interdependencies: that’s not my own idea. I copied it from the complexity scientists.
    – About moving from a local optimum: YES! that’s what my next article (the sequal to this one) is going to be about. 🙂
    Thanks for your input!

How to Change the World - free Workout - free
CLOSE