|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.