Twenty years ago, I was an accidental presenter at a Siebel conference. My boss asked me to take his place a couple of days prior on account of conflicts. He sent me the PowerPoint pack he had prepared on the topic—The Benefits of RAD for a Siebel implementation. RAD stands for Rapid Application Development. His style was not mine, and I not only had to digest his intent, I needed to internalise it to make it mine; otherwise, I’d have been just reading from a script, which is not my style or comfort zone. But Let’s rewind.
In 2002, I was the CRM Engineer at Stamps.com. I was responsible for all of Siebel, which included CRM, SFA, Customer Service, and Quality Management. I was the development manager for this group, and I acted as business analyst and programmer in this role. Thankfully, we had a legitimate Quality Assurance discipline with whom I partnered. I was also the project manager for coordinating any work. That’s due to earlier events.
Stamps.com thrived during the dot.com bubble, and it survived the dot.com bust. Project and programme management functions were the first to go as Stamps went through three rounds of layoff. Roughly speaking, they went from 600 to 300 to 150 to 60.
I survived all three cuts. After the first cut, my boss told me the decision was to privilege doers over planners. I was a programmer. We were doers. Without any project coordination functions in place, my productivity dropped to about a third. As much as I besmirch project management as a discipline, the coordination function is critical. In any case, this was a role I had to pick up, and in a zero-sum world, my heads down programming time had to take the hit. But I digress.
I had been successfully employing RAD for about 5 years at that point. Before Agile stole the spotlight, it was the thing—iterative waterfall. In fact, for the modern enterprise it’s all but forgotten, but it’s far superior to Agile. Agile is for startups and greenhouse projects. Full stop.
RAD had many of the same aspects as Agile but without the pretence. The work was iterative. I had 6-week release cycles, early participation by stakeholders and QA functions. Because I managed the entire Siebel ecosystem—someone else kept the hardware up and running—, I cycled through the functional areas in 6-week increments—CRM/SFA, Customer Service, and QM; rinse and repeat. To be fair, QM almost never needed 6 weeks and often got skipped due to a lack of feature function requests. This meant that someone else would get to start their cycle earlier.
This pattern and my advocacy created a trust bond, a bond absent from most organisations I’ve consulted with since. No one felt they needed to ask for everything plus the kitchen sink because they knew they’d get their turn in another 6 to 12 weeks. It’s the same methodology as used in preschools when they use a talking stick. People learn to wait their turn, and the stick will return to them to allow them to have a voice.
Essentially, this was the story I wanted to tell. And so I did. I don’t even remember where I flew to present. I remember my 20-minute speaking slot and still not being intimately comfortable with the pack I was talking over, though I had amended it to allow me to express myself. It went off without a hitch. I got a few questions from the audience and a nice Siebel-branded fleece pullover that was loved and worn for years to come. Rest in peace.
I think it’s long past time to revisit RAD and apply learnings from Agile. This could make RAD even better. In fact, the learnings are less from Agile then some of the peripheral notions of customer centricity, test and learn paradigms, light but adequate documentation.
RAD doesn’t presume a gaggle of generalists, which enterprises routinely ignore anyway. I like Agile’s ideal of self-organising teams, but enterprises ignore this aspect too. Enterprise Agile implementation is like going to ordering an omelet and telling the waitperson that you’d like cheese, bell peppers, onions and tomatoes, but hold the eggs—and add pickles and chocolate sprinkles. When they return with your order, you complain that they’ve not delivered you an omelet.
For Enterprises, Agile is an invalid selection. It requires a lot of trust—trust in the process and trust in the people. These are rare commodities in enterprises. And it doesn’t scale—something necessary for enterprise-level implementation.
Feel free to create epics and user stories. You’ll still need to handle use cases and acceptance criteria. You can still have a prioritised backlog. If you want to label the accountable party a Product Owner, go for it. You may not have a truly self-organising team, but you don’t have that now, but give them autonomy and space to operate. Teach them the business need and how it connects to the ultimate enterprise strategy. It’s not enough to ask them to insert tab A into slot B. Give them the “why“. Expose them to the stakeholders. Allow them to interact—asking questions and sharing ideas and insights.
In the end, RAD is plenty Agile and it doesn’t force the enterprise into living a lie and insisting that the emperor is in fact wearing clothes, when it’s obvious he’s not. This is crazy-making when an employee’s experience and lived reality doesn’t coincide with what they are being told. I’d better end here before I go off on some Orwellian 1984 tangent.
What do you think about the prospect of using RAD over Agile in your workplace? Leave a comment.