The Scrum Framework was developed by Ken Schwaber and Jeff Sutherland in the 1990s and first formalized in 1995 to address the inherent complexity of product and software development. More recently, the Scrum Framework is being applied successfully to complex problems in a wide variety of domains, like marketing, organizational change, and scientific research. The Scrum Framework is built on three pillars that allow empirical control:
- Transparency: you gather data — like metrics, feedback on the product, and other experiences — to find out what is going on;
- Inspection: you inspect the progress with everyone involved and decide what that means for your ambitions and work together;
- Adaptation: you make changes that you hope will bring you closer to your ambitions;
“The cycle of transparency, inspection, and adaptation, repeats as frequently as necessary to catch deviations, unexpected discoveries and potential opportunities that emerge as the work is done.”
What is Made Possible by the Scrum Framework
The empirical approach that the Scrum Framework offers becomes tremendously useful when you accept that you don’t know and can’t control everything. Because of that, your understanding of what is necessary will change, you will make mistakes and new and valuable insights will emerge that you never considered initially. Instead of making a precise plan upfront and then sticking to it no matter what, you can treat the ideas you have as assumptions or hypotheses that you validate through working with the Scrum Framework.
The Scrum Framework allows you to learn whether you’re off track and need to make adjustments much sooner than when you’re simply following a plan. Instead of going all-in on one solution, you’re now able to tackle the biggest risk you’re facing first.
This is especially important when you’re operating in an uncertain, changing environment. Assumptions you may have had at the beginning may have been absolutely correct at that time. But while you’re developing your product, the context may shift so much that your whole approach flies out of the window. Instead of catastrophic failure at the end of a long project, an empirical approach reduces that to a minor speed bump that requires you to correct the course a bit.