The Shock Therapy according to Scott Downey

The SHOCK THERAPY RECIPE

In order to cut standard Team Discovery or Novice Leadership bootstrapping times by 50% or more, the following steps were used at MySpace when orienting the teams into a proper Scrum posture. These steps can be easily implemented by an experienced coach.

For a novice ScrumMaster, failure to implement these steps will consistently incur the cost of poor velocity and quality. The results here can show the novice ScrumMaster which are the important features of Scrum that must be implemented to guarantee high performance. Novices will have to do their best to convince teams to follow best practices. For teams in this paper, the ScrumMasters had enough experience and management support to enforce the right practices and the leadership capability to get the teams to cooperate.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 advice, “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.

Advertisements

About ProjectServant

Project Manager Business Analyst

Posted on April 20, 2011, in Agile, Collaboration, Leadership, Scrum. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: