Agile Zone is brought to you in partnership with:

Jim Highsmith is an executive consultant at ThoughtWorks, Inc. He has 30-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. Jim is the author of Agile Project Management: Creating Innovative Products, Addis Wesley 2004; Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House 2000 and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, Addison Wesley 2002. Jim is also the recipient of the 2005 international Stevens Award. Jim is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Once Upon a Time before Agile

07.18.2013
| 3872 views |
  • submit to reddit
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!

famous-fairy-tales
Image Source: Themes Company

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.

Published at DZone with permission of Jim Highsmith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: