"Shorting development cycles through sprint planning was a key learning in the 2-day Scrum course; a learning that will make it easier for me to hit my project goals."
- Kelly Wald, LaserFiche

>> Read more testimonials



Subscribe to Scrum Users

ScrumDevelopment Archive
Introduction to Scrum

Scrum Process Overview
A practitioner of Scrum describes it as a "hyper-productivity technique." Scrum increases the relevant productivity (that productivity that generates used products) far beyond popular and expensive fads. Scrum is not an acronym. First used to describe hyper-productive development in 1987 by Ikujiro Nonaka and Hirotaka Takeuchi, Scrum refers to the mechanism used in rugby for getting an out-of-play ball back into play. Scrum generates productivity improvements by implementing a framework that empowers teams and thrives on change. A set of rules and corresponding terminology are used to reinforce such common sense techniques as small teams, daily status meetings, not interrupting people who are working, and a single source of work prioritization. Scrum's two pillars are team empowerment and adaptability :
  • Team empowerment : Once teams are given work to do, they are responsible for figuring out how to do it. The team does the best it can during each increment. While a team works, their only interaction with management is to tell management what is getting in their way and needs to be removed to improve their productivity.
  • Adaptability : Scrum uses "punctuated equilibrium". The team maintains an equilibrium during each increment, insulated from outside disturbance. Increments are punctuated every thirty days so that the team and management can evaluate what should be done during the next increment; this decision is based on what the team has accomplished and what the environment dictates is the next most important thing to do.
Once Scrum is underway, teams and management find it easy to focus, every request is easily evaluated by, "What's that got to do with delivering the code?"

The "Flip"
Scrum is gradually implemented to get everyone used to the mechanics. Then, we do the flip.In the flip, management is there for the development teams, rather than the development teams being there for management. Management focuses daily on two things :
  1. Is there anything in the way of the developers, and the removal of these impediments.
  2. What is most important software for these teams to built.
Teams focus on one thing : building quality software (and ignoring everything else).The flip returns management to their most effective role : determining the right things to do, and removing anything in the way of the teams being able to build software. In this way, the teams are as effective and productive as possible.

In many organizations, management gets in the way of the teams. This is inadvertent, but asking for reports, weekly status meetings, presentations to their boss, participation in offsites are all tremendous impediments ... both in time and the way that they interrupt the thought process that creates good systems.

The flip has management attend daily team status meetings - where the team shares status with each other, and then lets management know what can be done to make them more effective. The flip is that management is there for the team once they start developing. This is a stark contradiction to most development environments.

The flip is subtle but powerful. Managers live and breathe to help the teams. Nothing is more important. If the team needs meeting rooms, an executive can do nothing better than move out of their corner office to make sure the team keeps charging ahead.