For those working in a traditional Waterfall project management environment, the idea of moving to Scrum can be a bit unsettling, knowing that they’ll be building products without complete sets of requirements upfront.
However, once they understand the principles behind Scrum and perhaps even try a small-scale project using Scrum, the anxiety surrounding the transition usually dissipates.
Unlike Waterfall where months are spent gathering requirements before a single line of code is written, Scrum gets a project in motion with a high-level vision of the product, and enough of the requirements (stored in the Product Backlog) to get the project going. And the team then continues to iterate at short but regular intervals (usually two to four weeks, called Sprints) to buildout the product.
Waterfall used to be the predominant way software were built back in the days of PalmPilots. However, the ubiquity of mobile devices and affordability of cloud technologies, combined with consumers’ increasing tendency to move on to the latest and greatest tech gadgets have made it difficult for organizations to look into the crystal ball and build for the long term.
Scrum is not suitable for every project. For example, employing Scrum for building simpler applications with limited features would probably be an overkill. But for a vast majority of organizations building complex software, an agile approach such as Scrum provides control and agility to adapt to the fluidity of the marketplace with less financial investment upfront.