A. Scrum is an Ecosystem

Experienced agile coaches recognize that Scrum is based on complex adaptive systems theory. It is not a methodology, process, or procedure. It is a framework based on enforcement of simple constraints that will cause a average team to self-organize into a hyper-productive state [6].

Figure 1. Scrum is an ecosystem.

When implementing Scrum, it is therefore essential to understand Scrum as an ecosystem of interdependent parts. Each of the three Scrum roles (Product Owner, Scrum Master, and Team) is dependent upon every meeting, artifact, and best practice in the ecosystem. If any part of the ecosystem is dysfunctional the whole system deteriorates to only small gains in performance and quality.

B. Strategies for Implementation

Most previous Scrum implementations at MySpace and Jayway were based on "Team Discovery" or "Novice Leadership." Individuals read some books, get some training, and start implementing Scrum while inspecting and adapting. This leads to a hybrid implementation of Scrum where keys pieces are deemphasized or missing (ScrumBut [7]). For example, informal surveys show that 50% of the Scrum teams worldwide cannot get software tested at the feature level by the end of a Sprint violating the second principle of

the Agile Manifesto. This creates increased rework and poor performance.

MySpace and Jayway needed a way to start up a new Scrum team where important constraints are enforced that consistently deliver hyperproductivity in a short period of time. Here, we present an approach that works in waterfall environments even with minimal management support.

The different between this and "ordinary" Scrum is that:

* Coaches did not wait for teams to self-organize on their own. The method and technology was firmly established. The team learned to self-organize while following these constraints.

* Acceptance test driven development was used (ATDD). Testers/business analysts would deliver test cases that were implemented directly by the programmers. Only after this was the actual code completed. Testing was accomplished as soon as possible after code completion and before the end of the sprint. The need for ATDD as best practice has been carefully documented by Systematic Software Engineering [8, 9].

A. Lay the Foundation

Novice Leadership and Team Discovery approaches at MySpace and Jayway allowed the teams to become distracted by new terminology, roles and artifacts. In the absence of strong, experienced leadership, most teams spent their formative months focused on aspects of the framework rather than on delivering value to the customer. They also under-emphasized or failed to implement critical elements of the Scrum Framework, which sets them up for limited success at best.

These mistakes often led to a measurable initial reduction in value delivery rather than the expected increase that drove the decision to implement Scrum. To avoid this pitfall, the Shock Therapy coach, Scott Downey, fully enforced the complete Scrum Framework for teams described here. Scott found it was critical at the outset that the entire team participate in training so that everyone had the same

understanding of goals, mechanisms, definitions, and responsibilities they will share going forward. Teams in this study have participated in an internally developed Introduction to Scrum course that covers the Twelve Points of Scrum as well as the most impactful environmental factors of the MySpace technical and organizational structures. Until the Scrum Product Owner, Scrum Master, and entire Delivery Team participate in training, no further steps are taken to bootstrap that team.

B. Stabilize the Environment

The legitimate degrees of freedom in the Scrum Framework are often confused with Framework elements themselves. This can lead to accidental, dysfunctional hybrid models. Having a strong, experienced, and empowered coach is critical to getting teams functioning

quickly and realizing the benefits of Scrum. To achieve this, the Shock Therapy Coaches at MySpace and Jayway take many of the legitimate degrees of freedom off the table by providing an additional but temporary structure that could be viewed as a "Default Profile" for new teams. Through practice and demonstrated proficiency, teams earn the right to change these Default Profile settings (but never the Scrum Framework).

Before changes in the Default Profile could be made, the teams in this study were required to complete three consecutive, successful Sprints, demonstrate a 240% increase in Velocity, and have a solid business reason to make a change that was agreed to by all team members.

Default Profile rules were applied consistently for the MySpace teams in this paper. At Jayway the same conceptual approach is used with minor variations.

* Set Sprint Length The Shock Therapy Coach decides Sprint Length. Shorter Sprint lengths are recommended to facilitate more

rapid inspect/adapt cycles. All teams in this study used one week Sprints.

* Set the Definition of Done The Shock Therapy Coach provides an initial definition of Done that should be applicable to 80% of the work the team will pursue. Our initial definition of Done includes, at minimum:

* Feature Complete

* Code Complete

* No Known Defects

* Approved by the Scrum Product Owner

* Production Ready

Although approval of delivered work is the domain of the Scrum Product Owner, during the Shock Therapy experience, the Coach must also agree that the work has met the agreed state of completion or s/he, too, can reject the work and direct it back to the Product Backlog.

* Strictly Filter User Stories

Only properly formed and supported User Stories are allowed into the Sprint by the Coach. Improperly formed Product Backlog content is rejected by the Coach on the team's behalf before the Planning Meeting.

* Sprint Backlog Items

Sprint Backlog items are accepted at the highest level of granularity that passes the INVEST mnemonic [2]. At no point are cards broken into a list of tasks in pursuit of a task list alone.

* Only Estimate in Story Points

Estimation is in Story Points only. No estimates in Hours are ever solicited or tracked, and team members are discouraged from thinking of tasks in terms of time.

* A Physical Scrum Board Must Exist

A physical Information Radiator is designed by the Coach and serves as the focus of the daily 15-Minute Stand-Up Meeting. The simplest board with the minimum number of columns is recommended. Teams in this study used boards that displayed only Product Backlog, Sprint Backlog, Work In Progress, and Done. No "Waterfall" columns (e.g. Design, Dev, QA) were allowed. A physical board will be maintained even if software tools are used to provide visibility to remote locations.

* Respect for Team Meetings

A penalty for tardiness or unexpected absence from any team meeting is agreed to and enforced by the team. It applies equally to all team members, regardless of rank, role or excuses.

* The Sprint Planning Meeting will be 10%

The Sprint Planning Meeting will be 10% of the Sprint length in duration, and will include Sprint Review, Retrospective, Product Backlog Presentation, Estimation and Commitment of the Team.

C. Building Muscle Memory

During the Sprint, the Coach needs a singular focus on adherence to the Scrum Framework and Default Profile rules. It is best that s/he not be distracted by feelings of ownership over either the Product or the code. S/He must prevent multi-tasking, enforce working in priority order, encourage collaboration on the highest priority, and maintain the Scrum Board until the Team takes these things over,

which usually happens naturally in the first several Sprints.

The Coach must constantly explain both rules and rationale used to derive advice or correction. As an example, when a lower priority card completes and the team member asks for more work, the Coach should not just advise, "Take the top item from the Product Backlog." Rather, s/he should step them through the logic. "Can you help expedite any card that is already in progress? If not, can you work on any of the committed cards that are not yet started? If not, is there a better way to redistribute work across the team based

on your availability right now? If not, retrieve the highest priority item from the Product Backlog and commit only to as much as can be completed by the end of the Sprint."

It is important to engage the team in problem solving rather than always solving the problems yourself, as a Shock Therapy Coach. When the Coach notices someone multitasking, a team member not paying attention during the meeting, an Information Radiator that is not moving properly, or any other systemic or behavioral sub-optimizations, s/he should ask the team if they notice anything happening that should not be happening. Ask them to find and correct the defects and be available to help them if they begin to fail.

D. Seek Your Exit

At no point during Shock Therapy can the Coach become personally involved or vital to the team's success beyond the bootstrapping experience. The Coach must not take on any fundamental tasks or fill in for any missing team members. It is critical to remember that the purpose of a Coach is to create self-sufficiency within the team. S/he must not become a foundational element of it and should seek to

relinquish authority, leadership, and artifacts as soon as the team demonstrates an ability to absorb them.

A. Establishing Baseline Velocity

The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points [10]. The team selects what can be accomplished during the Sprint and the Product Owner determines exactly what is "Done" at the end of the Sprint. The number of story points completed is the baseline velocity.

B. Myspace Team Data

Data on five teams at Myspace is summarized in Figure 2. The solid line in the middle of the graph is average velocity for all teams for each Sprint. The lines the teams. The lower dotted line is 240% percent of baseline velocity and the goal at MySpace was to achieve this in three one-week Sprints. Teams that achieve this typically go over 400% (upper dotted line) into a hyperproductive state in later Sprints. The low data points were from the only team where the MySpace Agile Coach did not assume the Scrum Master role. The existing Scrum Master failed to enforce constraints.

Figure 2. Velocity of MySpace Teams by Sprint