Given its empirical nature, scrum fits this environment perfectly. Scrum doesn’t tell you how to do anything. It simply lets you see clearly (that is, exposes) what you’re doing and assess from there.
A huge variety of languages, tools, methods, and platforms exist to solve these complex problems. Scrum doesn’t tell you which ones to use. Rather, this framework lets teams self-manage to decide which ways are best for their circumstances. Scrum does this through unfettered transparency, frequent inspection, and immediate adaptation.
The very nature of scrum allows you to find solutions every day, in every sprint, and with every release. Both the product and the process are nurtured for creativity and excellence.Traditional project management methods and frameworks are predicated on being able to accurately predict the future. They’re linear and sequential. They act as a waterfall. (You can read about waterfall approaches in Agile Project Management For Dummies, Second Edition by Mark C. Layton and Steven J. Ostermiller [published by John Wiley & Sons, Inc.].) What’s important to understand is that technology and design needs have far outgrown this change-averse framework.
Waterfall project management entails progressively maturing a set package of requirements in different stages; completing one stage before moving on to the next, such as designing all requirements for the entire project before doing any development and completing all development work before doing comprehensive testing, which is left to the end. With scrum, these phases are cycled repeatedly throughout a project so that a continuous circle of design, development, testing, integration, and feedback is achieved each day, sprint, and release.
As projects became more complex, the natural boundaries of waterfall became abundantly clear. Multiple phases and long delays existed before coding even began. Early performance was no indicator of later performance because each phase’s tasks were fundamentally different; code testing was loaded toward the end of the project, when the team had the least amount of time or money; and customers didn’t interact with the product until it was too late to incorporate their feedback. Projects were delayed or never completed, and often they came up short.Scrum emerged from the need to find better ways to build software. Keep in mind, however, that the scrum framework can be applied to any project in which you can encapsulate the work and prioritize an item against other items.
Winston Royce and scrum
In a strange quirk of history, the man mistakenly attributed with introducing the waterfall framework to large software projects emphasized the basic agile and scrum principles: inspect and adapt.Winston Royce was a computer scientist and a director of the Lockheed Software Technology Center. He published a paper titled “Managing the Development of Large Software Systems,” in which he described several methodologies, including waterfall and an early iteration of agile.
Royce clearly warned about the pitfalls later to be endured with waterfall. It’s strange that the very system he’s mistakenly credited with inventing is the same system he warned about. He wrote:
“The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed …. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated.”
Royce said that leaving testing as a separate phase at the end was “risky and invited failure.” He suggested an iterative approach that tested frequently and made adaptations based on the results. Every step linked back to the previous one.