Prototyping and Agile: Twins, Separated at Birth? We have written before about the intelligent application of Agile methods in Information Technology (IT) projects. See part 3 of our 4-part 2011 series, The First 10% of a Project: 90% of Success, here in our ChangeAgents articles. This article is a follow up with more insights. And, much has happened since our earlier article.
Agile is now maturing, and moving beyond the last-half-of-the-IT-life-cycle. For example, we have seen excellent discussions on the “hybrid” approach. This involves using Agile where it is most appropriate (and where the prerequisites are in place). It also involves using other insightful pm methods where they are more appropriate. That approach in IT, plus increasing use of Agile concepts in areas such as New Product Development, shows promise.
I do still have concerns about a few of the agile zealots who insist upon contrasting Agile to Waterfall. Competent PMs moved away from “pure” Waterfall in the early 1980s. We also disposed, for the most part, of years-long, hold-your-breath-and-wait-forever IT projects. And, we eliminated the reams of never-used unneeded documentation–retaining only the useful stuff. What did we replace these 1960s-era artifacts with? Three-to-six-month, intensive bursts (we called them iterations) that delivered prioritized useful business functions.
Prerequisites for Success
In addition to speeding useful delivery, we also identified and implemented other key prerequisites for project and business success:
- A good, high-level project plan.
- A clear business case.
- Understanding of the information needs and data structures.
- Customer-driven high-level business requirements.
- Risk assessment, and mitigation responsibilities.
- The right talent assigned, the right amount of time; both on the IT side, and from customers.
- Facilitated sessions (Rapid Initial Planning and Joint Application Design) for fast project planning, and requirements elicitation in 1-2 weeks.
- And, all the other factors mentioned in part 3 of our Success series, mentioned above.
In recent articles and presentations, I am seeing Deja Vu in some of the rediscovered insights that Agile practitioners are applying. This is especially important as they move from focusing on the last half of the life cycle or life span. For example, presenters speak about how they decide which parts of a hybrid IT project are best-suited for an agile approach. Some, who are more helpful, also point out which parts should use classic methods. Many show an understanding of the advantages and requirements of each approach. But still, there is something missing—a logical and rational way to decide the most-appropriate approach.
And now, I can explain the title of this article. I solved this problem—for a different advancement—Prototyping—over thirty five years ago. Ironically, Prototyping and Agile share a strong set of parallels.
DeJa Vu Context
In the early 1980s, many IT groups were moving from third-generation languages such as COBOL to higher-level languages. These new languages were improving coding throughput by a factor of 2-3x. Excited about the prospect of these power-languages, developers were interested in “getting to code” much quicker. They thought the then-classic Structured Systems Analysis methods to be a waste of time, and began “prototyping” their code. They adapted an approach Engineers had used for years.
Of course, this meant they needed to sit down with their customer, show what they had produced, and quickly make improvements. They did this both for displays and for reports. And of course, all the prerequisites we spoke of above, were still essential—especially if the system involved new data.
But the most enthusiastic “new way” proponents were adamant that everything should be prototyped. To them, all other approaches were the old way. And their new way needed no requirements, no documentation, and seldom even needed testing. All that overhead “stuff” was a holdover from the past—they claimed.
A Prototyping Solution
After a few sessions of guiding these prototyping bright lights to higher ground, I came up with a solution. I too had been an early adopter of both high level languages, and of prototyping. As a manager, I had transformed entire organizations to their use. And, I understood both their prerequisites, and benefits. So I built a table that identified a range of attributes about the system, sub-system or business process being developed. Here’s copy of that table (updated for readability), from around 1983. 
The instructions directed developers to use the table to evaluate their system or application to determine which type it was: Process-oriented, or Information-based. For each factor, rate the application by circling 1 to 6, depending on how well it met each process-oriented or information-based test.
One outcome: They sometimes found that they did not know the answers—yet they were still eager to develop the solution. So they performed business analysis (yes, we called it that back then) to resolve the open items. They then followed our steps to analyze and evaluate the results:
Scoring Results
Add the circled scores, divide by 8, and truncate any remainder. Based on the resulting score, decide the most appropriate approach:
- Systems scoring 1 or 2 are process-oriented. You should use classic structured systems analysis, aided by prototyping of all information outputs during requirements definition.
- Systems scoring 5 or 6 are primarily information-based, and are good candidates for delivery using iterative Prototyping.
A system that scores 3 or 4 is a mixture. Decompose it into its sub-systems, and re-evaluate them against the factors. Repeat for any sub-system scoring 3 or 4, until you get to detailed processes.
We found a lot of results that we called Zorro, or zigzag systems: The circled scores showed as one or more Zs down the chart. This situation required that decomposition process mentioned above. Because this approach gave developers a rational process, it caught on very quickly. Even project managers, project customers, and managers liked the approach. And, we used that interest to get those key prerequisites into place—especially those involving the right customers—still a challenge today.
We integrated this chart into our commercial methodologies. We also added them to the many home-grown and commercial methodologies for which we did methods improvement. And, the last time I looked at the chart was in 1987—until one of those “Hybrid Agile” presentations tweaked my memory.
We found that teams that knew enough to confidently score their system were able to produce much better early estimates. Even before they had business requirements.
Applicable to Agile?
I do not profess to be an Agile expert. I did follow Scrum from the early 1990s, when a business partner asked for help in relating Scrum to project management. He was working on integrating his facilitated requirements analysis with Scrum. As an early advocate of Extreme Programming, I also like DSDM and the various Crystal methods. I view the Crystal collection as true life-cycle-wide Agile approaches.
There exist dozens of new ideas in the practice of competent and performing project management. Agile methods (depending on the flavor) can offer significant benefits when used wisely, and significant risk when mismanaged. For example, I’d be very careful with Agile around Regulatory projects that have high consequences. But Agile has built on the smart PM practices of the 1980s, and added useful concepts, principles, tools, and expectations.
But I have a question: How would you change the Prototyping chart shown above to adapt the factors to Agile’s key decision points? I think many of the factors might be the same. The question about Data, for example, is important; it affects whether the project builds the database, or uses it. If it builds the database, huge amounts of regression testing will follow. Not very agile!
So, dear reader, what is your opinion on this question: What would you change to help identify where Agile methods work best? Given the savvy insights of those who are practicing Hybrid Agile, I’d bet you have some great suggestions to share…