Category Archives: Scrum
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.
- 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 . 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 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.
Implementing standup meetings or in scrum – daily scrum meetings should be not be too serious about the roles of its participants in the chicken and pig roles because if your team falls under this misconception then you become a slave of the concept.
Remember collaboration is a key.
The Scrum Master should be master of your of interaction – he/she must be sensitive and listen to his team.
The team should know what to do after each daily scrum meetings. PDCA is key – Plan/Do/Check/Act.
Still I cannot get over it…. yesterday I was able to finish the training for SCRUM Master but it just keep rubbing in. It seems that the trainors of SCRUM is saying to me that SCRUM is the only methodology that practices MACRO Management in a project.
If in any case you are a project manager in any industry may it be IT, Software, Hardware, Construction, etc…. this is a trait of a good project manager if one would macro manage and still knows what is being done by your teammates. A good project manager is not just command and control but he listens a lot.
I have been in the IT industry for quite some time now and I believe that a PM or any lead should have the following traits:
- A good listener
- is Proactive
- inspire a shared vision
- provides Win-Win Solution
- has the trait of a problem solver
- has team building skills
- can influence people even if he has no title
- has the ability to delegate tasks
- is cool under pressure
- has self-mastery on what he/she do
- has integrity
- and a good communicator
I am now a Certified Scrum Master…… but I don’t feel to be a master 😦
I think the concepts was presented well but it seems that I have an impression that people who are doing scrum are rebellious in a sense. One of the trainors (Bas Vodde) who I assume is leader in the SCRUM community for me is purist in a sense.
Personally I think the training of CSM should be attended by Project Managers, Lead Developers, Business Analyst and Managers but most of the people who attended the training were developers who do not have any experience in leading a team so I think it is very dangerous for this people to attend this kind of trainings because in implementing scrum one should have a concepts of managing and leading a team.
The concept of SCRUM is so simple yet so hard to implement.
Bas Vodde, one of trainors who I would label as a purist in SCRUM and a SCRUM coach in my own personal opinion lacks the maturity be one. Maybe, I am too direct in my choice of words but during the Q&A for the CSM training he was dodging every question of the class and could not answer most of questions in a manner that a mentor or a coach should be answering.
He said “keep the Project Manager out of the picture when you are implementing scrum“. He is adamant in saying that project management is not a good idea but SCRUM is distributing the function and roles of Project Management in the Product Owner and the Scrum Master.
When a coach would say that he don’t see any need for an audit or a process and to keep management away I feel that concepts of the coaches mind is distorted. SCRUM in itself is a process of delivering a project while audits is still needed because any customer-vendor relationship would want to have a snapshot what is happening on a project and management would always be there because they are the ones who paying the delivery team.
This is so sad to hear from an author, mentor and even as a SCRUM coach.