Once Upon a Time before Agile


Image Source: Themes Company

Once upon a time, before “agile”, the IT world teemed with scary monsters—huge methodologies in multiple 3-ring binders, processes stacked upon processes and excruciatingly detailed documents ad infinitum. This was the 1980’s when proponents of methodologies such as Information Engineering spent 18-24 months in strategic IT planning before any projects were started! Another 18-24 months for the first project delivery—so some companies poured 3-4 years into “revitalizing” IT before realizing any value. In the early 1990’s customers reacted to these long delays and Rapid Application Development (RAD) was born. One of the traditional methodology vendors responded to this nascent trend by releasing a RAD methodology—they merely took out 1/3 of the tasks in their “monster” methodology!

In early 1991 I got a phone call from Sam Bayer, then marketing manager for a company that sold an expensive rapid development tool. Sam (who is now the CEO of b2b2dot0 and has been a good friend of mine since those early years) expressed his frustration, “IT executives know their delivery cycle is way too long and they need shorter ones, but we’re experiencing very long sales cycles with this new RAD tool of ours. People just don’t know how to use it and are skeptical of the benefits.” Sam had called me because he heard I knew something about RAD (very little at the time, but I winged it). He wanted to put together a RAD methodology with their tool and conduct short pilot projects to provide a proof of concept to potential clients.

With Sam’s marketing background and my software development experience, we developed a methodology for his company’s pilot projects. We combined, among other things:

  • A short 1-2 day project inception process with all stakeholders
  • Four-week timeboxed projects with 1-week iterations
  • Working, tested software features at the end of each iteration
  • Skeletal release plans for the project and more detailed iteration plans
  • Showcases at the end of every iteration (we called them customer focus groups then)
  • Minimal documentation, maximum collaboration
  • Cross-functional, collocated teams.

Time after time we delivered these pilot projects with high-value features, on time. We used function point calculations and industry statistics to consistently show 4-6 times industry productivity averages. Quality was high. End customers were excited, IT staff not always so much. After an early showcase a senior customer SVP stood up and remarked, “Wow, I’ll never say anything bad about IT again.” She couldn’t believe there was actually working software in a few weeks. Sam and I published an article, “RADical Software Development,” on our experiences in the American Programmer Magazine in June 1994.

So the scary monsters were vanquished—right? Of course wrong. Successful projects ran up against organizational anti-bodies. “We don’t believe your data. Of course, you had a small project, it would never work on larger projects. You had the best people. It would never work with legacy systems; you had a green field application.”

There is an irony about problems and solutions that never fails—people want solutions to long-standing problems, however, they don’t want to change. My favorite story about this topic comes from Alistair Cockburn. In talking with a client with a significant development problem, Alistair said, “Try A.” To which the reply was, “We can’t do A because of …” So on to the next recommendation, “Try B.” To which the reply was of course, “We can’t do B.” So the client says, “What’s next?” Alistair’s classic reply, “I think you should sell your company stock!”

So does this story have a happy ending? Since at its core agile is about reflecting, learning and adapting—there really isn’t an ending. In the beginning, the monsters were really big and scary. The Agile Manifesto authors and others struggled during the decade of the 1990’s and early 2000’s to bring legitimacy to practices that are mainstream today. But there are always new monsters and new challenges, naysayers and foot draggers—but also a constant stream of exciting new people to take up the challenges. There may not be a happy ending, but there are always victories worth celebrating before moving on to the next challenge.


    1. Thank you Jim for this post! I have been frustrated with the “We can’t do that because” or “our environment is so different that your idea does not apply here..” answers.
      These answers put me back into my early Agile projects where I heard (and even used!) the same dismissals to trying out new ideas.
      Keep banging on this because it is happening again! Don’t believe me? Just search for #NoEstimates on twitter….

    2. Nice article. Reminded of early days when we used to spend months together collecting requirements !!

    3. The mind boggles why people are reluctant to even try something different, thank goodness most of them don’t own their own business. I’m sure their outlook and approach would be so different if it was their money on the line. #justsaying

    4. Hey Jim,

      Thanks for the stroll down memory lane. I’m really happy to see that 20 years later, the RADical concepts that we set forth are still in “vogue” today.


    5. Tom Minick says:

      The story reminds me of one of the great taglines of all times, and very appropriate for this topic, Nike’s “Just do it “.

      I remember using this as a kind of mission statement for a small “agile like” team back in the late 80’s with great success.

      Thanks Jim

    6. Arielle Hurst says:

      It’s crazy to read how much I take for granted as a newcomer to the development world. I can’t imagine how much farther behind technology would be today if those long, tedious documentation practices were still the “only way”.Clearly a disruptive methodology can be as transformative as a disruptive technology!

    7. Jim,

      Thanks for a very nice post. You reminded of the organizations which are still spending months for collecting the requirements and then keep on changing the requirements during the software development time which make all the projects over budget and over time. Some organizations still very reluctant to change their culture to adopt Agile methodology and they are paying the price of paying more and spending more time on most of the software development project. It is always being frustrated to hear the words like “We cannot adopt agile methodology in our organization as it will be very difficult to change the culture, Our top management will not support agile”


    Speak Your Mind