domain.dot.net team

08.12.08

The Real Agile from 1973 : Expanded Discussion of the factual basis for Software as ‘Wicked Problem’

What’s your opinion on the genesis for a new software process/method entering the mainstream?

They don’t emerge as collective practice from air.

What made waterfall become a shared mental belief system in millions of minds yet fail so consistently, and indeed provide the only level of ‘predictability’ in software at that time (an expectation of predictable disaster).

I could continue on the facts above for a few pages but it merely is an example of our need to carefully choose a belief system that actually has the added value of being correct.

in terms likely unseen (and unknown by most)    What do you believe the memes for successful adoption are? Why did waterfall dominate for so long and at such pain?

For this discussion, your opinion of why Agile succeeded yet while it also brings impassioned opposition from others is a focus of thought.

Yet indeed while software is filled with so many amazing minds why do we fail on the most basic and fundamental topics more as a rule then exception (code reuse for example is still an utter failure for no reason other than human constraints. The technology has existed for well over a decade if not more).

Mental models/belief systems around software development drive ‘methods/methodologies’ for implementation. Unfortunately, many fallacies define the standard for how others perceive ‘how the work should be performed’.

  • The needs of our stakeholders are perfectly reasonable given their perspective and perhaps not always wrong (but clearly so historically).
  • Their amazement at our inability to perform to their expectations are not new and in most cases would be expected if the facts discussed here were made explicit.

This has been the shame of software for decades, as we seem to have a terrible time growing into a mature field of science. There is far too much failure, lack of predictability, and utter frustration at the highest levels of corporations globally. What happened and why is Agile / Wicked Problem thinking so helpful?

What are some of the reasons this disconnect exists?

Enter Agile

Agile was and mostly is the best approach to resolve the most painful aspects of fitting an artisan’s model into an assembly line mentality. Agile reconciles organizational needs in software around previously unrealistic demands around predictability, verifiable estimations, and planning.

Buzzwords and industry hyperbole aside, Agile has moved our industry forward in fundamental ways. We believe this is mostly around its focus on team-centric behaviors and simply not watering down the statement of facts around software most in the ‘methods’ world could never do as it would sever their ability to be embraced! Agile simply told the truth and said ‘enough is enough’ let us do this using some common sense.

‘Wicked Problems’

Now consider a model already used in many domains that goes back to 1973. This model has already defined the very drivers of ‘what is software development’ we assert. Consider the following:

NOTE: For a more complete listing and discussion please see [3]

If you cannot admit 90% of these statements below about software, why would you believe Agile would work for you?

  • You do not understand the problem until you have developed a solution.There is no definitive statement of “The Problem.” The problem is ill structured and composed of an evolving set of interlocking issues and constraints.
  • Wicked problems have no stopping ruleSince there is global/definitive “Problem” (for example a software system is often perceived as different depending on the context of the stakeholder/user being asked), there is also no definitive “Solution” as each perspective has a different ‘optimal’ end-state. The problem solving process ends when you run out of resources. and/or a ‘good enough’ compromise is met for all the drivers behind a project.
  • Every wicked problem is essentially unique and novel.There are so many factors and conditions, all embedded in a dynamic social context, that no two wicked problems are alike, and the solutions to them will always be custom designed and fitted.

Every solution to a wicked problem is a “one-shot operation,” every attempt has consequences.

This is not around all code being written from scratch in the least. This means that the delivered software for a wicked problem is unique but almost always composed of other ‘non-wicked’ solutions..

Who would even consider delivering a strategic application where nothing is leveraged from others?

Wicked problems have no given alternative solutions.

There may be no solutions, or there may be a host of potential solutions that are devised, and another host that are never even considered. This is the nature of solving complex and ‘moving target’ type concerns

Mock Frameworks are a Mandate

Although a side discussion, we believe it merits your attention as we simply have no idea how anyone can succeed at Agile without a Mock-Centric world.

Consider an ‘API’ you require but is now ill defined and not even built. Do succeed this API must ‘appear to exist and indeed appear to be working’ to our system as we evolve items around it. For example, a complex API for financial calculations is assumed, but at iteration three we only required a few aspects of that API.

For more discussion on this critical yet later stage topic go here for our deeper discussion

Facts will not Save Us

1) It is irrelevant how correct the above is until external, internal or a combination of forces move the collective thought.

Typically, the competitive market and legislation protecting shareholders should resolve the glaring nature of this issue. However, it is ignorant for we technologists to believe the ‘objective truth’ of our knowledge will directly drive cultural shifts. It does not happen that way in most cases. If it did we would all have OS/2 running on our machines and beta-max machines.

2) Most cannot actually act on these facts or even acknowledge their reality.

This is of course due to their having to ‘change everything’ in how their fiefdoms execute, not to mention trying to explain this to the other stakeholders of IT. I see disastrous practices perpetuated rather than trying to actually be viewed strategically in the value they could offer their organization.

Conclusion for Now

Ask yourself these questions at the most fundamental:

  • Does your culture understand and nurture ‘software as iterative learning and Wicked Problem’.
  • If so can you only acknowledge this fact with your team (that’s fine, as good luck explaining this to most C-Level execs. In fact we recommend not mentioning Agile unless they mention it to you first.
  • How do you treat short-term failures from iterative development (assuming a strong set of feedback loops allowing constant course correction and validation)?
Digg This

3 Comments »

  1. Damon .. Nice piece. The Knol for reference [3] gives an error 404 for me. Is it just me?
    Jeff

    Comment by Jeff Conklin — 08.17.08 @ 11:37 pm

  2. Jeff,

    Yeah the Knol people changed the URL a while ago. It was updated but might have been cached somewhere along the pipleine.

    Try this link.

    Thanks!

    Damon

    Comment by Damon Wilder Carr — 08.18.08 @ 10:25 am

  3. Ah I misread. However reference [3] to the always excellent work of the Poppendiecks is : http://www.poppendieck.com/wicked.htm.

    Your organization (CogNexus) looks incredibly interesting. I’ll be sending you some private email for inquiry. I had no idea anyone was doing this incredibly important work. And your in Napa, right down the road from where I grew up (grin).

    Damon

    Comment by Damon Wilder Carr — 08.18.08 @ 10:35 am

RSS feed for comments on this post. TrackBack URI

Leave a comment

Blog at WordPress.com.