Agile software development is iterative and incremental in nature as I discussed previously in Agile Methods Provide the Greatest Value to Organizations. Its earliest manifestation is probably in work performed by IBM in the late 1950s, albeit the term agile didn’t become popular until a group of forward thinking individuals developed Manifesto for Agile Software Development in 2001.
For this particular post we focus on just one of the agile methods called Scrum. As defined in the Scrum Guidebook, Scrum is…
- A lightweight framework… sort of a recipe designed to help teams deliver quality software at a sustainable pace.
- Easy to learn… and this article provides all of the information you’ll need for understanding its basics.
- Difficult to master… in the sense that ‘practice makes perfect.’ Scrum is an elegant method (framework) but understanding its nuances, developing teams into high performing value-producers, and carrying that value to the rest of the organization takes time, effort and patience.
Origin of the Term “Scrum”
The term Scrum derives from the sport of rugby and is shorthand for scrummage, a term that was later adopted for use in American Football after changing it to scrimmage. A scrum is literally a means of “pushing a ball forward” in the rugby pitch and involves many “interconnected players” working together on each respective team.
Just as in the sport of rugby, we use Scrum to indicate a team endeavor to “push a product forward,” to increase its value and to delight customers who use the product.
Origin of the Agile Method Called “Scrum”
In 1985, Hirotaka Takeuchi and Ikujiro Nonaka used the word Scrum in the HBR Article entitled The New Product Development Game to connote continuous innovation in product development.
Ten years later, Ken Schwaber and Jeff Sutherland presented the rudiments of a Scrum framework at the object-oriented conference OOPSLA 1995. They have been collaborating since that time to introduce ever greater clarity and maturity to Scrum.
Scrum, an Important Agile Method – er Framework
Scrum’s roots lie in empiricism which is the idea “…that knowledge comes from experience and making decisions….” Engineers typically call this feedback, which is information that can be used immediately to correct a course of action when needed. Scrum is based upon three pillars (a.k.a precepts, dogma, supporting thesis, … ):
- Transparency: All members of the team can see – and if desired, understand – any of the work, and results, associated with the product: Its origins, importance to the organization, “code,” user stories, etc. Nothing is hidden from team members.
- Inspection: Identify – at discrete points in time – whether the path the team has taken will indeed result in achieving the goals established for the current lifecycle (increment). This can be done in the day, the sprint, the release, and/or the strategy cycles.
- Adaptation: Scrum teams are self-organizing; so, based upon results of inspections, the team might choose to modify its own behaviors (tasks, communication, etc.) to more closely meet the established goals, or perhaps to use empirical evidence to pick better goals.
Team Values
Scrum teams operate under the following five team values:
- Commitment: Scrum goals guide the team. Commitment means that every team member is committed to reaching these goals.
- Focus: The work – required to achieve the Scrum goals – is what is important and is, therefore, the focal point.
- Openness: In short this means that we will not hide product, team or organizational information that may produce important insights.
- Courage: This should ring true with every software developer who ever lived. Sometimes doing the daunting or difficult tasks takes courage. Scrum purposefully incorporates this concept because, when working with a team that has shared goals, it tends to be self-supportive.
- Respect: As you might imagine, this may be the most important of the Scrum values.
Note: If a Scrum team member is found to “not work out” in the sense of not being an engaged, productive member of a team, it is probably because they do not – or can not – fully embrace one or more of these values.
The Scrum framework prescribes:
- Roles: Who does what?
- Artifacts: Living documents that help the team focus on what’s most important at every point in time.
- Events or ceremonies: Prescribed meetings, each with a specific purpose.
Scrum Roles
The roles in Scrum teams are:
- Product Owner: Literally the individual who is responsible for understanding the product, its value to the organization and its customers, and the primary contact or bridge for stakeholder feedback and involvement.
- Scrum Master: A servant leader: An individual who works for the entire team as a facilitator and coach; a person who is never a legitimate authority such as a Manager or former Project Manager. Scrum does not, and cannot, work in a command + control environment.
- Development Team Members: Typically cross-functional in nature, this is the set of individuals who execute the tasks required to meet the product goals in the current increment.
Definition
sprint (noun) \ ˈsprint \ – a timebox of fixed length – typically 1, 2, 3 or 4 weeks in duration – used to mean “one complete lifecycle” in the Scrum framework. Each lifecycle begins and ends within the confines of this timebox.
Scrum Artifacts
These are the documents we use to make choices about the work we intend to do and a means of understanding how we’re doing as we progress toward work completion.
- Product Backlog: Owned and updated by the Product Owner, this is a prioritized list of user stories, each of which informs the Scrum Team what specific work needs to be performed.
- Sprint Backlog: This is the portion of the Product Backlog that is accepted for execution and completion during the current sprint.
- The Increment: The potentially releasable “Done” product work that is created during the sprint.
Scrum Events
These are the prescribed meetings that occur in every sprint.
- The Sprint: A time-boxed container during which all currently ready and accepted stories are brought to life in code and which will meet the Definition of Done (DoD).
- Sprint Planning: Typically occurs on the first day of each new sprint. Within this meeting we choose the sprint goal from among the priorities set forth by the Product Owner in the Product Backlog.
- Daily Standup (the Scrum): A meeting that includes all Scrum team members. It lasts 15 minutes or less. During this time period each member of the Development Team announces three things… (1) What was achieved since the previous Standup; (2) What will be the focus of work today; and (3) What, if anything, is standing in the way of getting that work done. The Scrum master is in attendance in a supporting/facilitative role only. The Product Owner is there to observe progress and to help answers questions, but only after the Standup meeting has ended.
- Backlog Refinement [not an official Scrum event] (formerly known as backlog grooming): Occurring perhaps once or twice each week during the sprint, these meetings help the entire team to break down user stories in the Product Backlog in preparation for accepting new work in the very next sprint to follow.
- Sprint Review: Occuring on the last day of each sprint, this meeting is attended by the full Scrum team plus any stakeholders who are interested in the outcomes of the current sprint. The review is sometimes conducted by members of the Development Team and sometimes by the Product Owner. The purpose of the meeting is to agree that the sprint goals were successfully met; or, if not, what adjustments need to be made.
- Sprint Retrospective: Also occurs on the last day of each sprint and is facilitated by the Scrum master. This is an opportunity for Development Team members to share “What went well during this sprint?” and “What might we change in order to do better next time?
The Power of Scrum
Generally speaking, the agile philosophy takes advantage of the notion that “two heads are better than one,” which is nicely explained in the book We are Smarter than Me: How to Unleash the Power of Crowds in your Business by Barry Libert and Jon Spector. In essence, agile prescribes that teams of highly focused individuals own sets of problems (products), the solutions (improvements) to which provide value for the company. Scrum is an effective and elegant means of maximizing this value.
