The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
The Agile Manifesto doesn’t provide concrete steps. Organizations usually seek more specific methods within the Agile movement. These include Crystal Clear, Extreme Programming, Feature Driven Development, Dynamic Systems Development Method (DSDM), Scrum, and others. While I like all the agile approaches, for my own team Scrum was the one that enabled our initial breakthroughs. Scrum’s simple definitions gave our team the autonomy we needed to do our best work while helping our boss (who became our Product Owner) get the business results he wanted. Scrum opened our door to other useful agile practices such as test-driven development (TDD). Since then we’ve helped businesses around the world use Scrum to become more agile. A truly agile enterprise would not have a “business side” and a “technical side.” It would have teams working directly on delivering business value. We get the best results when we involve the whole business in this, so those are the types of engagements I’m personally the most interested in.
What’s interesting about Scrum?
Scrum’s leading advocate was inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Scrum uses real-world progress — not an uninformed forecast — to plan and schedule releases. Time is divided into short work cadences, known as sprints, typically one week or two weeks long. At the end of each sprint, stakeholders and team members meet to see a demonstrated potentially shippable product increment and plan its next steps. This allows direction to be adjusted based on completed work, not speculation or predictions.
Scrum is a simple set of roles, responsibilities, and meetings that never change. If Scrum’s capacity for adaption and flexibility makes it an appealing option, the stability of its practices give teams something to lean on when development gets chaotic.
Scrum has three roles: Product Owner, Scrum Master, and Team.
Product Owner: The Product Owner should be a person with vision, authority, and availability. The Product Owner is responsible for continuously communicating the vision and priorities to the development team.
It’s sometimes hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.
- Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and the team. The Scrum Master does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. This helps the team remain creative and productive while making sure its successes are visible to the Product Owner. The Scrum Master also works to advise the Product Owner about how to maximize ROI for the team.
- Team: According to Scrum’s founder, “the team is utterly self managing.” The development team is responsible for self organizing to complete work. A Scrum development team contains about seven fully dedicated members (officially 3-9), ideally in one team room protected from outside distractions. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. The team has autonomy and responsibility to meet the goals of the sprint.
When several teams work on one product, they should generally use a single Product Owner (who can make real business decisions) and a single Product Backlog with customer-centric requirements. Each Scrum team should strive to become a feature team, able to build a complete slice of product which could be delivered to a customer. When interdependencies arise, Scrum’s feature teams must learn to use team self organization principles to coordinate with other teams. Unfortunately, most teams are not initially accustomed to this level of responsibility, and pre-existing management habits and hierarchies present organizational impediments. While optimal Agility requires fundamental changes to organizational design, it’s tempting to use one of the hybrid approaches that combine a watered-down version of Scrum with traditional hierarchical management. Large organizations that are more committed to the values and principles of the Agile Manifesto are advised to learn about Large Scale Scrum (LeSS).
Online Scrum Master training is available in the Scrum Training Series, a free collection of entertaining e-learning modules covering an Introduction to Scrum, the Backlog Grooming Meeting, the Sprint Planning Meeting, the Daily Scrum Meeting, the Sprint Review Meeting, and the Sprint Retrospective Meeting. You can download the 6-page Scrum Reference Card or learn what the Scrum Master does. In person Certified Scrum Master training, typically using group immersion activities and case studies, is also available all over the world.
Leave a Reply
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013