You might be familiar with the traditional way of doing software development, called waterfall. This methodology is very linear, with a “big bang” delivery at the end. You start with requirements, move to software design and development, then testing and finally implementation.
The major challenges with the traditional waterfall approach include:
- A large investment in upfront requirements gathering, which often leads to outdated requirements documents
- Lack of foresight into the end product, so if the original requirements are off, you don’t have the opportunity to fix them before the software is put into production
- Difficulty in adjusting priorities if there are changes in the business environment; in other words, a lack of flexibility.
Scrum, an Agile methodology, is based on emergent requirements and small, incremental deliveries; with “inspect and adapt” serving as the guiding principle. This framework enables collaboration between the business and delivery team early and often, improving the overall quality and accuracy of the deliverables.
A foundational element of Scrum is called a Sprint; a time-boxed regular, repeatable work cadence (Celerity's Agile teams use two weeks for a Sprint length). At the end of each Sprint, the team delivers a ‘potentially shippable’ increment of the final product to the users. At this time the collective team and stakeholders together review what is delivered and the team adjusts priorities as necessary. This ensures that two very crucial things happen:
- Assumptions made during the Sprint were valid, meaning they built the right thing
- The most important activities are being worked on in the next Sprint (priorities can be adapted).
In addition, Scrum clarifies accountability with the definition of two roles. The Product Owner (business advocate) is a single individual who is responsible for maximizing the return on investment on the project. The Product Owner does this by choosing the next items of work, called Backlog items. By choosing these on the basis of value, the Product Owner ensures that the development team is always working on the most important things. In essence, the Product Owner is responsible for the ‘what.’
On the development side, the Scrum team is composed of 5-9 people and includes every skill necessary to create the deliverables (Design, Development, Analysis and Testing). The servant leader of the team is called the ScrumMaster; he or she facilitates the activities of the team and holds governance over process, the ‘how.’ The teams are self-organized; this increases intra-team transparency as the “community” of developers knows what everyone else is working on and where they stand against the goal of the Sprint.
But back to the original question - why do you care?
Scrum enables users of the system to see deliverables on a Sprint-by-Sprint basis. This increases the likelihood of the development team delivering what the users want and decreases the risk that the business has invested in bad software. Because Sprints are used, priorities can be shifted from Sprint to Sprint, ensuring the delivery of the greatest valued features while given the forum to provide feedback as progress is made. The Product Owner is clearly accountable for the business requirements and priorities, the ‘what.’ The ScrumMaster is clearly accountable for the output of the delivery team, the ‘how’. There is less ambiguity, more accountability, greater transparency and overall greater likelihood of success.
What’s holding you back from trying Scrum?