Agile Development and Scrum

The Agile family of development methodologies was born out of a belief that an approach more grounded in human reality would yield better results. Agile emphasizes building working software that people can get hands on with quickly, versus spending a lot of time writing specifications up front. Agile focuses on small, cross-functional teams empowered to make decisions, versus big hierarchies and compartmentalization by function, and Agile focuses on rapid iteration, with as much customer input along the way as possible. Often when folks learn about Agile, there’s a glimmer of recognition – it sounds a lot like back in the start-up days, when we “just did it”.

One of the fastest-growing Agile methods is Scrum. It was formalized over a decade ago by Ken Schwaber and Dr. Jeff Sutherland, and it’s now being used by companies large and small, including Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne and the US Federal Reserve. Many teams using Scrum report significant improvements, and in some cases complete transformations, in both productivity and morale.

For product developers – many of whom have been burned by the “management fad of the month club” – this is significant. Scrum is simple, powerful, and rooted in common sense.

Results From Scrum

The benefits of Scrum reported by teams come in various aspects of their experience. At
Yahoo!, we have migrated nearly 90 projects to Scrum in the last 30 months, totaling almost
900 people, and the list of teams using it is quickly growing. These projects have ranged from consumer-facing, design-heavy websites like Yahoo! Photos, to the mission-critical back-end infrastructure of services like Yahoo! Mail, which serves hundreds of millions of customers; they range from entirely new products like Yahoo! Podcasts, which used Scrum from concept through launch (and won a Webby Award for best product in its category that year), to more incremental projects, which included work on new features as well as bug fixes and other maintenance; and we’ve used Scrum for distributed projects, where the team is on separate continents. Several times each year we survey everyone at Yahoo! that is using Scrum
(including Product Owners, Team Members, ScrumMasters, and the functional managers of those individuals) and ask them to compare Scrum to the approach they were using previously.
Some summary data is presented here:
Productivity: 68% of respondents reported Scrum is better or much better (4 or 5 on a 5- point scale); 5% reported Scrum is worse or much worse (1 or 2 on a 5-point scale); 27% reported Scrum is about the same (3 on a 5-point scale).
Team Morale: 52% of respondents reported Scrum is better or much better; 9% reported
Scrum is worse or much worse; 39% reported Scrum is about the same.
Adaptability: 63% of respondents reported Scrum is better or much better; 4% reported
Scrum is worse or much worse; 33% reported Scrum is about the same.
Accountability: 62% of respondents reported Scrum is better or much better; 6% reported Scrum is worse or much worse; 32% reported Scrum is about the same.
Collaboration and Cooperation: 81% of respondents reported Scrum is better or much better; 1% reported Scrum is worse or much worse; 18% reported Scrum about the same.
Team productivity increased an average of 36%, based on the estimates of the
Product Owners.
85% of team-members stated that they would continue using Scrum if the decision were solely up to them.

Daily Scrum

Once the Sprint has started, the Team engages in another of the key Scrum practices: The
Daily Scrum. This is a short (15 minutes or less) stand-up meeting that happens every workday at an appointed time, and everyone on the Scrum Team attends; in order to keep it brief, everyone stands (hence “stand-up meeting”). It’s the team’s opportunity to report to itself on progress and obstacles. One by one, each member of the team reports three (and only three) things to the other members of the team: What they were able to get done since the last meeting; what they’re hoping to get done by the next meeting; and any blocks or impediments that are in their way. The ScrumMaster makes note of the blocks, and then helps team members to resolve them after the meeting. There’s no discussion during the Daily Scrum, just the reporting of the three key pieces of information; if discussion is required, it takes place right after the meeting. The Product Owner, Managers, and other stakeholders can attend the meeting, but they should refrain from asking questions or opening discussion until after the meeting concludes – everyone should be clear that the team is reporting to each other, not to the Product Owner, Managers or ScrumMaster. Some teams find it useful to have the Product
Owners join and give a brief daily report of their own activities to the team, though this is at the team’s discretion.
After the meeting, the team members update the amount of time remaining to complete each of the tasks that they’ve signed up for on the Sprint Backlog (figure 5). Following this update, the ScrumMaster adds up the hours remaining for the team as a whole, and plots it on the
Sprint Burndown Chart (figure 6). This graph shows, each day, how much work (measured in hours or days) remains until the team’s commitment is completed. Ideally, this should be a downward sloping graph that is on a trajectory to hit zero on the last day of the Sprint. And while sometimes it looks like that, often it doesn’t. The important thing is that it show the team their actual progress towards their goal – and not in terms of how much time has been spent so far (an irrelevant fact, as far as Scrum is concerned), but in terms of how much work remains – what separates the team from their goal. If the curve is not tracking towards completion at the end of the Sprint, then the team needs to either pick up the pace, or simplify and pare down what it’s doing. While this chart this can be maintained electronically using Excel, many teams find it’s much more effective to do it on paper taped to a wall in their workspace, with updates in pen; this low-tech solution is fast, simple, and often more visible than an electronic one.

Agile Development and Scrum

The Agile family of development methodologies was born out of a belief that an approach more grounded in human reality would yield better results. Agile emphasizes building working software that people can get hands on with quickly, versus spending a lot of time writing specifications up front. Agile focuses on small, cross-functional teams empowered to make decisions, versus big hierarchies and compartmentalization by function, and Agile focuses on rapid iteration, with as much customer input along the way as possible. Often when folks learn about Agile, there’s a glimmer of recognition – it sounds a lot like back in the start-up days, when we “just did it”.
One of the fastest-growing Agile methods is Scrum. It was formalized over a decade ago by
Ken Schwaber and Dr. Jeff Sutherland, and it’s now being used by companies large and small, including Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE,
CapitalOne and the US Federal Reserve. Many teams using Scrum report significant improvements, and in some cases complete transformations, in both productivity and morale.
For product developers – many of whom have been burned by the “management fad of the month club” – this is significant. Scrum is simple, powerful, and rooted in common sense.