The Anchor

Posted by Doc
Nov 14 2009

In Agile software development, we talk about learning from the past in order to improve the future. As I spend time with clients, whether doing coaching or training, I find them burdened by the past.

The Anchor.

“That’s the way we’ve always done things.”

Resistance to change for the sake of resistance.

Those of us who have had opportunity to work on and with Agile teams have seen what a difference that shift in principles, practices, and thought makes.  It makes a difference in the pleasure and pride that team members find in what they do. It makes a difference in the quality of the product they create.  It makes a difference in the overall competence of the team, both as individuals and as an entity.

Waterfall, on the other hand, has led to unhappy team members and failed projects.  Demonstrably.  In one report, the Standish Group found that only 34% of software projects were unqualified successes. While it says that the percentage was up to 34%, I still find that to be a discouraging statistic.  What’s encouraging is this:

Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward.”

So here we have an approach, along with a set of practices, that has been shown not to work for years, even decades, and yet managers or organizations hang onto it like it’s a life preserver, when in fact, it’s an anchor.

Drop your anchors. What is so frightening about not buying into the fallacy that you can know everything up front, plan everything up front, budget everything up front…?  Well, it goes on and on.

Of course you need to be able to plan and budget. But I don’t buy into the idea that anyone believes that those numbers are real or accurate. Rather, it’s “the way we do things” and they are resistant to change and the unknown.

Cast off your anchors! Learn from the mistakes we’ve been making for 50 years and find better ways to do things.  Let’s deliver better software with fewer defects that meets the needs of the customers/users, delivers more value, and does so when it says it will.

6 Responses

  1. Twitter Comment


    Blogged: The Anchor [link to post]

    Posted using Chat Catcher

  2. […] The Anchor (Steven ‘Doc’ List) – Link of the Day […]

  3. […] This post was mentioned on Twitter by Steven (Doc) List, planettw. planettw said: Steven List: The Anchor: In Agile software development, we talk about learning from the past in order to improve th… http://bit.ly/4y7CCF […]

  4. Sumeet Moghe says:

    What happens when Agility is your anchor? I’m referring to the dogma of following practices only because they’re ‘important’. One of the biggest problems with Agilist dogma is that we often approach every broken machine with our bag of tools and then try to find the nuts to tighten with these.

    As a stark contrast, yet as an amazing complement, there’s the Lean Toolkit that allows you to see what the problem really is and then apply the right tools or approaches to solve it. The right approach/ tool may be agile or not!

    • Doc says:

      It sounds like you’re saying “to the man with a hammer [Agile], everything looks like a nail”. Being dogmatic about Agile can definitely be a problem.

      I think there’s great value in the Lean Toolkit. Are they at odds with what many think of as Agile? Or is there some intersection and synergy?

Trackback URL for this entry

%d bloggers like this: