Editor’s note: An earlier version of this post contained mistakes and lacked clarification around several key points. Our thanks to Mishkin Berteig for spotting these errors and to Robert Half’s own ScrumMasters, Ketan Khatri and Peggy Graves, for helping to address them.
Scrum is a widely used process framework for Agile software development. In concept and practice — e.g., the use of Sprints, Sprint Reviews and Retrospectives — Scrum is distinguishable from other frameworks. Scrum is a methodology that is often used to manage complex development in iterative and incremental practices, and it allows teams to adjust so they can accommodate evolving goals and requirements during development.
Clear, Open, Nimble
Scrum processes reflect Agile’s emphasis on collaboration and creating working components quickly. Scrum teams optimally comprise seven people (plus or minus two) working in a self-organizing way without traditional titles like “tester” or “architect.” Instead, every team member collaborates and organizes to meet the objectives laid out and prioritized in the backlog.
Scrum.org identifies these central roles on a Scrum team:
- Product Owner — This role determines what needs to be built and manages the product backlog. The product owner functions as the voice of the customer, prioritizing backlog tasks and working toward business goals.
- Development Team — These are the builders. They develop according to the priorities set by the Product Owner but are self-directing owners of the process.
- ScrumMaster — Some describe SMs as the sheepdogs of the Scrum, and that analogy fits. They act as buffers between the team and the outside, ensure the Scrum process runs as it should and remove impediments.
Time is on Our Side (Yes, it is)
Like other methodologies for applying Agile to software development (think XP and DSDM), Scrum employs a fast, iterative approach to design,development and test. To accomplish this, the team uses open and frequent communication. Team members perform tasks in work cycles called Sprints that typically last one to four weeks each. Some teams use an “off” week between Sprints to hold a Sprint Retrospective.
Work progresses according to two timing cadences: the Sprint cycle and daily activities, which are sometimes referred to as ceremonies. Rick Freedman, author of three books on IT consulting, describes three Scrum ceremonies:
- Sprint Planning Meeting — This meeting takes place as the Sprint begins to determine what work will be done. Here the team, with the ScrumMaster and the product owner, conceptualizes the roadmap for the Sprint and defines what work will be done.
- Daily Scrum — Every day during the Sprint, the team gathers for 15 minutes to report on accomplishments and impediments. These briefs often focus on answering three questions: What did I accomplish yesterday? What’s going on today? What obstacles are impeding my process?
- Sprint Review — This is a post-Sprint meeting in which developers demonstrate new features. The product owner evaluates new features and discusses any business or marketplace changes before selecting the next items to be developed.
The Scrum Guide by Ken Schwaber and Jeff Sutherland includes one additional meeting type: the Sprint Retrospective. This session enables the team to reflect on other areas for improvement, such as team interaction, tools and processes.
To Scrum or Not to Scrum?
If you’re thinking about transitioning development teams to a Scrum model, it might be useful to pose these questions to stakeholders: Do we struggle to determine what the client/customer really wants? Are we competing in a fast-moving field? Do we value collaboration and speed over linear processes?
Scrum advocates a process that offers time benefits over traditional frameworks that rely on linear workflows. As work moves in Sprints, development teams can account for business-requirement changes quickly. Because features can be demonstrated on a frequent basis, any feedback that alters the project’s direction can be addressed sooner, allowing the least amount of timeline delay.
But is Scrum always preferable? Within certain industries or team structures, different frameworks may work better. Another consideration: If the process your team employs is working, why reinvent the wheel? Some also contend that with slow-moving processes or fully remote teams, Scrum may not be the most efficient option.
The biggest roadblock preventing a shift to Scrum — or any Agile framework — occurs if everyone on a team isn’t committed. Success depends largely on the organizational culture and a team’s ability to make a shift in process and delivery. Scrum is not a silver bullet, but when it works as intended, it can empower development teams, improve business processes and result in a better end product.
Share your experience with Scrum (or any other Agile framework) in the comments.