Originally published on Scrum Alliance.
My current journey begins in August 1970, when Dr. Winston W. Royce presented his views on "Managing the Development of Large Software Systems" at the proceedings of IEEE WESCON. This revolutionary paper introduced software engineers like me to the world of Waterfall (or, as I like to call it, "what-the-fall"). But we usually skipped the part in our textbooks where Dr. Royce himself stated that pure Waterfall software development would never work. Dr. Royce stated that in order to eliminate most of the development risks, five additional features must be added to the basic what-the-fall approach.
Program design comes first. Although one can criticize this step's legitimacy since it’s introduced even before analysis, Dr. Royce suggests it’s worth identifying and defining a number of nonfunctional requirements, even at the risk of being wrong.
Document the design. When asked how much documentation, Dr. Royce says, "quite a lot," certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices.
Do it twice. Dr. Royce says that in order to deliver better software, the final delivered version for operational deployment must actually be the second version as far as the critical design and operations areas are concerned.
Plan, control, and monitor testing. There are a few things Dr. Royce suggests here: Have specialists who did not contribute to the original design test many parts. Involve a second party for visual scans and inspections. Test every logical path at least once, using a numerical test. Decide who is the person responsible for the final check, and use a computer since it’s the best device for this.
Involve the customer. Because software design is subject to wide interpretation, even after the previous agreement, it is important to involve the customer, who is formally committed toward regular checkpoints before final delivery.
For me, this is the first "manifesto for software development," because it provides the general guidelines for better software development. When I coach Agile software development (or simply "Agile"), I always trace back to this document. I see that the rules of software development are still the same, but the way we achieve better development has changed drastically.
Have things really changed?
We still code the design first, with the difference that it is done in a more Lean fashion. The concepts of fail fast, experimentation, and feedback still apply along the lines of the first point Dr. Royce made. Although people would argue over the point of extensive documentation — in Dr. Royce’s defense, he was a rocket scientist — his definition of extensive documentation may have been equivalent to sufficient documentation with Agile. And documentation has necessarily not reduced; it’s just become more scattered, such as in clean code, comments, tests, extracted designs, conversations over documents, etc.
Although the way documentation is achieved with Agile might have changed, the efforts spent on building this knowledge has definitely increased, and for good reasons. We don’t do things twice anymore; we possibly do them many more times. These are simply achieved through spikes and code refactoring. Testing has become more streamlined and quick with automation; testing every logical path at least once, using a numerical test, is now achieved through test-driven development. This also makes it easier to refactor frequently and use an automated, continuous computerized pipeline to check out the deliverables, just as Dr. Royce suggested. And I guess we don’t need to convince anyone about the benefits of interactions and customer collaboration.
Now the question is that if these concepts of software development were known in 1970, why did we wait 30 years before addressing them as Agile software development? The answer seems simple. Over the years, the only thing that has remained constant is our curiousity to find better ways of developing software. This has led a number of iterative and incremental methods, including Scrum and eXtreme programming (the usual two that I practice), among others. So far, the Agile Manifesto, along with its 12 principles, is the one that accommodates most of the existing and upcoming good practices from various software development methods and frameworks. Having said that, we may find ourselves at a crossroads with a new manifesto sooner or later. Until that time, the Manifesto for Agile Software Development as we know it will suffice to add the common sense into software development.
Why do we need frameworks?
For many people, Scrum seems synonymous with Agile, and for obvious reasons. It is the most widely known software development framework, as are its certification bodies, and it sees its image in the Manifesto. It is one of the simplest frameworks, easy to understand (bloody difficult to implement); and what I like most about it is that people are curious to understand it (each person with their own breaking point to let it go). So the next question is, if the Agile Manifesto governs the principles of good software development, why do we need frameworks like Scrum? Why can’t every team (every organization) create a framework around the principles of the Agile Manifesto?
I guess the answer to that question is that common sense isn’t that common. And although we would wish to imitate the most sensible person around, the truth is that we can only retrospect common sense, and our present actions cannot guarantee it. We have frameworks so that we can retrospect on the good practices and hope that the framework that we have identified works in our favor. Regarding the second part of the question, many organizations have come up with their own Agile frameworks, especially with the advent of virtual and scaled teams. This is not to say that frameworks like Scrum failed to address scaling in the past, but LeSS, SAFe, and others make it easier for us to retrospect the common sense of scaled software development.
I find it odd, though, that we have gone full circle, whereby Dr. Royce started the journey with the management of large software systems, and today we are discussing large-scaled implementations. Obviously the context has changed, the demon is bigger to kill, and the race is faster than ever; but this raises a new question. Is it time already to identify the new set of principles that changes the face of software development? Perhaps that’s what Agile has preached for a long time: adapting to change over following a plan. The only way I see it happening is if the current followers understand the true nature of Agile software development, and unless we have good followers (I hope I’m one of them) and good leaders (I hope to be one of them), it would be difficult to identify.
To conclude, I hope to learn two things:
Have I considerably messed up the basics?
Do any of you foresee it going differently?