Some of you may remember the far away and long ago 1990s. A time when personal computers were a relatively new thing, software engineers had not been issued their standard hoodie uniform, and we had not yet heard of SCRUM.
It was a dark time when most projects followed a Waterfall software development methodology: teams specified requirements up front, coded, and then waited to test until all the development was done. More software projects failed than succeeded and countless hours were wasted. Frustrations mounted as the inadequacy of the Waterfall approach became more and more clear, making room for an alternative: agile development methods.
Scrum started out as just one of those methods. But while other agile approaches like Extreme Programming are still in use, Scrum now dominates the field. The Scrum Alliance reports that 66 percent of agile frameworks in use are Scrum or a Scrum variant. And there’s a good reason: A State of Scrum survey shows that 62 percent of Scrum projects succeed. A vast improvement over the gloomy 90s.
A Manifesto for a Methodology
To dispel the extreme level of frustration caused by the old methodology, the introduction of agile had to be strong and impassioned, not just a revised set of dry rules. Thus The Agile Manifesto was born. The manifesto didn’t propose a specific methodology. Instead, it addresses the heart of engineers’ concerns, defining the values and principles for how software development should proceed. Rather than being structured around rigid procedures and mandatory documentation (the main reason the Waterfall method failed), the manifesto stated that software projects should value:
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
The manifesto named principles in support of these values, including the goal of satisfying the customer by delivering software frequently and accepting changes to requirements.
How Scrum Works
Scrum methodology implements the manifesto’s principles in a straightforward way. The official Scrum Guide is only 16-pages long. Scrum projects are developed in short increments called “sprints” that take less than one month. Sprints require people in three roles, completing four tasks.
The Product Owner represents the customer and understands the product requirements. They manage the Product Backlog, which identifies and prioritizes the features to be developed.
The Development Team consists of the developers who do the work. Development teams are self-organizing and create their own efficient means of completing the work. Teams consist of all the job roles needed to complete the sprint’s work, not just programmers but also UI designers, QA testers and other staff.
The Scrum Master role is commonly misunderstood as a project manager, but that’s not the role’s purpose. They are masters of the Scrum process and make sure interactions follow Scrum principles. Their job is to facilitate getting work done in each sprint, but they don’t assign tasks and review completed work like a traditional project manager.
The end goal of each sprint is a new product iteration. This requires Sprint Planning before the sprint starts, a brief Daily Scrum meeting, and a Sprint Review and Sprint Retrospective after the sprint finishes.
Sprint Planning involves the whole Scrum team and determines the work for this Sprint. The Product Owner defines an objective for the sprint and identifies what items from the Product Backlog need to be developed to achieve that objective. The Development Team determines how those items will be built and creates a Sprint Backlog that defines their plan.
The Daily Scrum is the heart of the Scrum process. At a quick 15-minute meeting, the Development Team reports status and synchronizes the planned work. Any issues a team member is facing are raised at this meeting.
When the sprint is complete, a Sprint Review meeting looks over the work and makes adjustments to the Product Backlog. This meeting, unlike most Scrum meetings, can include participants outside the Scrum team. A separate Sprint Retrospective is limited to the Scrum team and focuses on how the sprint applied the Scrum process to help the team work more effectively during the next sprint.
Scrum Makes Developers, Customers and Managers Happy
So how does such a simple framework succeed while more structured waterfall processes fail? Scrum meets the needs of everyone involved with the product and also keeps in mind what makes us happy as human beings.
Scrum Meets Developers’ Needs
For developers, Scrum provides more autonomy than traditional methods. The team agrees to the work for a sprint and decides how the work will be performed. Everyone makes a commitment to get the work done. Daily meetings mean failure is visible, motivating team members to meet daily goals.
Scrum masters make sure teams communicate well and clear roadblocks, which cuts down on stress despite constant deadlines. Short sprints mean developers frequently experience successful deliveries, which feels good and adds to morale. That means developers are eager to get to work on the next sprint, too!
Scrum Meets Customers’ Needs
For customers, Scrum takes away the mystery of software development. Customers don’t simply hand over requirements and wait … and wait … and wait … to get software back. With short sprints, there just isn’t that much time.
There’s also never a long wait to correct a project that’s moving in the wrong direction. If business needs change, the priorities on the product backlog get updated right away and the next sprint planning meeting focuses on what needs to be done to meet the new goals without wasting time on the old.
Scrum Meets Managers’ Needs Because teams are self-directed, managers can focus on strategic work instead of day-to-day issues. They can feel confident in Scrum and get help as needed from a community that supports the methodology with books, online resources and tools. The Project Management Institute offers an Agile Certified Practitioner certification, so even traditional environments that rely on credentials can use Scrum to get the work done.
And that in a nutshell, is the beauty of Scrum. By paying attention to human nature, not spelling out all the details, keeping processes simple and the work transparent, Scrum adapts to every environment. It does just enough to help work get done without getting in the way.
Best of all, it can be adapted to work for virtually any team. At Gliffy, everyone including the Marketing team uses Scrum. Check out this blog post written by our Director of Marketing, Mark to get the details.