Overview:What is Scrum?

Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Its attributes are:

Scrum is an agile process to manage and control development work. Scrum is a wrapper for existing engineering practices. Scrum is a team-based approach to iteratively, incrementally develop systems and products when

requirements are rapidly changing Scrum is a process that controls the chaos of conflicting interests and needs. Scrum is a way to improve communications and maximize co-operation. Scrum is a way to detect and cause the removal of anything that gets in the way of developing and

delivering products. Scrum is a way to maximize productivity. Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized

development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.

Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Scrum naturally focuses an entire organization on building successful products. Without major changes -often within thirty days - teams are building useful, demonstrable product functionality. Scrum can be implemented at the beginning of a project or in the middle of a project or product development effort that is in trouble.

Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototyes. Based in modern

process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.

Over fifty organizations have successfully used Scrum in thousands of projects to manage and control work, always with significant productivity improvements. Scrum wraps an organization's existing engineering practices; they are improved as necessary while product increments are delivered to the user or marketplace. As heard about Scrum, "oh, that's just my idea X by another name". Except, Scrum is spelled out as values, practices, and rules in a development framework that can be quickly implemented and repeated.

Scrum has been used to produce financial products, Internet products, and medical products by ADM. In every instance, the organization was logjammed, unable to produce shippable products for such a long period of time that engineers, management, and investors were deeply concerned. Scrum broke the logjam and began incremental product delivery, often with the first shippable product occuring with the same quarter.

Scrum as applied to product development was first referred to in "The New New Product Development Game" (Harvard Business Review 86116:137-146, 1986) and later elaborated in "The Knowledge Creating Company" both by Ikujiro Nonaka and Hirotaka Takeuchi (Oxford University Press, 1995). Based on their ideas and research in process theory performed in collaboration with DuPont Advanced Research Facility, Scrum was first formulated and presented to the Object Management Group in 1995. The Scrum process is fully described in a recent book from Ken Schwaber and Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2001). An excerpt of that book can be read here.

How it Works:What is Scrum?A variation on Sashimi, an "all-at-once" approach to software engineering. Both Scrum and Sashimi are suited best to new product development rather than extended development.�� Sashimi originated with the Japanese and their experiences with the Waterfall model.�� They had the same problems with the Waterfall model as everybody else, so they adapted it to suit their own style.�� Realizing that speed and flexibility are as important as high quality and low cost they reduced the number of phases to four -- requirements, design, prototype, and acceptance -- without removing any activities, which resulted in overlap of the Waterfall phases.�� Then they made the four phases overlap.�� (Sashimi is a way of presenting sliced raw fish where each slice rests partially on the slice before it).�� Other companies took Sashimi one step further, reducing the phases to one and calling it Scrum.�� (A scrum is a team pack in Rugby, everybody in the pack acts together with everyone else to move the ball down the field). � Applying ScrumFor each Waterfall phase there are a pool of experienced people available, form a team by selecting one person from each pool.�� Call a team meeting and tell them that they have been selected to do an important project.�� Describe the project, include how long it's estimated to take, how much it is estimated to cost, how it is expected to perform, etc.�� Now tell them that their job is to do it in half the time, with half the cost, twice the performance, etc.�� Tell them how it's done is up to them and explain that your job is to support them with resources.�� Now leave.

Stand by, give advice if it's requested, and wait.�� Don't be surprised if a team member thinks the whole thing is insane and leaves.�� You'll get regular reports, but mostly you'll just wait.�� At somewhere around the expected time, the team will produce the system with the expected performance and cost. � How does Scrum work?The first thing that happens is the initial leader will become primarily a reporter.� �The leadership role will bounce around within the team based on the task at hand.�� Soon QA developers will be learning how requirements are done and will be actively contributing, and requirements people will be seeing things from a QA point of view.�� As work is done in each of the phases, all the team learns and contributes, no work is done alone, the team is behind everything.�� From the initial meeting, the finished product is being developed.�� Someone can be writing code, working on functional specifications, and designing during the same day, i.e. "all-at-once".�� Don't be surprised if the team cleans the slate numerous times, many new ways will be picked up and many old ways discarded.�� The team will become autonomous, and will tend to transcend the initial goals, striving for excellence.�� The people on the team will become committed to accomplish the goal and some members may experience emotional pain when the project is completed. � Why does Scrum Work?The basic premise is that if you are committed to the team and the project, and if your boss really trusts you, then you can spend time being productive instead of justifying your work.�� This reduces the need for meetings, reporting and authorization.�� There is control, but it is subtle and mostly indirect.�� It is exercised by selecting the right people, creating an open work environment, encouraging feedback, establishing an evaluation and reward program based on group performance, managing the tendency to go off in different directions early on, and tolerating mistakes.�� Every person on the team starts with an understanding of the problem, associates it with a range of solutions experienced and studied, then using skill, intelligence, and experience, will narrow the range to one or a few options.

Keep in mind that it can be difficult to give up the control that it takes to support the Scrum methodology.�� The approach is risky, there is no guarantee that the team will not run up against real limits, which could kill the project.�� The disappointment of the failure could adversely affect the team members because of the high levels of personal commitment involved.�� Each person on the team is required to understand all of the problem and all of the steps in developing a system to solve it, this may limit the size of the system developed using the methodology.

Observation:

Frequent, First-hand Observations

Scrum provides direct visibility into the progress of the project.

� Management can attend and observe the daily Scrum meetings. During these meetings they can observe team spirit, each member's participation, team member interaction, work that is being completed, and impediments to progress.

Management can attend and participate in Post-Sprint Meetings and Sprint Planning Meetings, where - based on progress to date and team capabilities - work is planned.

Scrum provides daily status on team progress, and iterative (every 30 days) reviews of product progress. Everything is visible - what's to be worked on, how work is progressing, and what has been built - supporting management decisions regarding cost, time, quality, and functionality. Plus, management is apprised daily what it can do to help the development teams - what decisions are needed, and what's getting in the way.

Burn-down Charts:

Work Burn-Down

Management is concerned about :

Sprint progress - how is the team doing toward meeting their Sprint goal? Release progress - will the release be on time with the quality and functionality desired? Product progress - how is the product filling out compared to what's needed?

� To answer these questions, you can assess Product Backlog, Release Backlog (product backlog that has been identified as required for the next release of the product), and Sprint Backlog contents and trends.

Each backlog item contains the amount of work remaining. These values are updated continuously. Plot this backlog across time. Even though you might think that backlog should always go down, new work is always being discovered as the product is being built. Expect the backlog to go up and down.

Plot the slope of the backlog. If you draw a line representing average slope over a period of time, you can project it to determine when no work is likely to be left (mission accomplished, Sprint goal reached, or release ready for finalizing). Team velocity=actual work completed/days to complete.

Manage empirically so that Sprint backlog and Release backlog reach zero when needed. You do this primarily by adjusting Sprint and Release contents or by modifying the Release date.

This type of management produces "the best possible software". The team is doing what they can and you are helping them as much as you can.

Every team has different signatures. Backlog trends and velocity represent these team signatures. You'll learn these signatures and be able to help teams adjust accordingly. For instance, some teams always have Sprint backlog that keeps going up during the first tpart of the Sprint, and then descends dramatically. Assess the measurements and determine whether this is because of inadequate Sprint planning, overwork during the last ten days (usually causes poor quality), or infrequent reporting of work remaining.

Each team member is responsible for estimating the number of hours remaining to complete all assigned tasks during a Sprint. As work is completed, new estimates (hours-effort remaining) are made until all work is

completed.� These estimates are then summarized for all tasks and converted to a burn-down chart which can be used to determine overall progress being made during the Sprint.

The Product Manager is responsible for maintaining Product Backlog, along with estimates for how much work is required for a backlog item. As Sprints build product, the Product Manager re-estimates (sometimes the feature is only partially implemented) or zero's (feature completed) backlog items.

Work remaining reporting during a Sprint focuses on updates to the estimated number of hours� to complete a task. This should not be confused with time reporting. At the beginning of the Sprint, each team member estimates the number of hours it will take to complete each of the tasks that they have been assigned for the Sprint period.� As the work is completed, a new estimate to complete is made for each task.� This process continues on a periodic basis until all tasks are finished during the Sprint.

Active Management:

Active, Intelligent Management

Scrum Requires Active, Intelligent Management

Management is actively involved with Scrum on a daily basis. At the daily Scrum status meeting, management listens closely to what each team member reports as being worked on. This is compared to what management expects should be happening. For example, if someone has been working on a trivial task for three days, it is likely that that team member needs help. Management also listens for the velocity of the team : are they stuck, are they floundering, are they making progress? Management can step in and problem-solve if help is needed.

Management is also responsible for keeping the team working at the highest possible level of productivity. When decisions are needed in the daily Scrum, make them then even if you have incomplete information. It's usually better to proceed with partial information. If enough information isn't available, create a backlog item to make the decision.

When impediments are reported during the daily Scrum - and the team cannot resolve the impediment themselves

- the Scrum Master is responsible for either solving it himself or causing it to be solved as soon as possible by personally escalating it to executive management of the organization. When the Scrum Master escalates an impediment, he makes visible to the organization a policy, procedure, structure, facility, etc. that is hurting rather than helping the organization perform its primary goal - to produce product.

Management is often surprised at some of the impediments. They were unaware that seemingly well-thought through initiatives, standards, structures, policies, etc. are getting in the way. The political turmoil that escalating impediments can cause shouldn't be underestimated. However, this lets the organization make the choice of what is the most important thing for them to do.

About XP:XP @ Scrum

Scrum has been employed successfully as a management wrapper for Extreme Programming engineering practices. Scrum provides the agile management mechanisms; Extreme Programming provides the integrated engineering practices. An article written by Ken Schwaber and Kane Mar on one implementation is at the Prentice Hall InformIT web site.

Benefits of xP@Scrum include:

1. The agile management and control mechanisms of Scrum are applicable for any type of project, including business initiatives that consist of multiple, simultaneous software development, business development, re-engineering, marketing, support, and implementation projects. xp@Scrum projects fit within the overall management framework of these initiatives.

2. xP@Scrum projects realize the full benefits of self-organization; teams are iteration (or Sprint) goal directed, rather than story directed.

3. When Extreme Programming projects are wrapped by Scrum, they becomes scalable and can be run simultaneously by non-colocated teams.

4. Scrum implements in a day; Extreme Programming can be gradually implemented within the Scrum framework.

5. xp@Scrum projects benefit from ADM's business value metrics process for measuring and managing initiative ROI.