How to Get Scrum Right on First Attempt

Single Sprint Scrum Pilot

Originally posted in: The Lean & Agile Practitioner

Takeshi Yoshida | Chief Coach & Founder, Lifecycle | Professional Scrum Master & Professional Scrum Product Owner (PSM II, PSPO, Scrum.org)

Pilot objective

Within the Scrum community, there is abundant writing suggesting that the two main factors of Scrum implementation failure are: (1) sub-optimal team structure at the onset, and (2) the Scrum Team failing to reach critical formation maturity early on. I second this observation from my own experience.

Failure itself is welcome in Agile, and all is good if the Scrum Teams can validate the learnings from the false start and adapt to improve. The trouble is that after a few Sprints of lackluster performance and failed launches of second and third Scrum Teams, many organizations (a) eventually give up on Scrum (with the “Agile doesn’t work” bitterness) or (b) continue with half-baked Scrums resulting in demotivated teams (i.e. “Zombie Scrums“).

So, is this a team problem? Actually, this is more of an alignment problem: misalignment between concurrent organizational values and Scrum values. In short, Scrum is a transformation from project management to product ownership culture:

Scrum is…

• Empirical instead of predictive. (In contrast to the plan and predict all-the-way nature of waterfall project management, Scrum is a practice of evidence based management.)
• Iterative instead of sequential. (Again, in contrast to the sequential project stage nature of waterfall.)
• Concentrated on gathering continuous feedback instead of gathering in stages. (Quality control is not a separate process in Agile.)
• Value-focused instead of deadline-focused. (Scrum shifts the focus of control from “time” to “continuous improvement” – there is little evidence that meeting deadlines correlate with value maximization; in fact, there is evidence of the opposite.)
• Self-organizing instead of control and command. (Project management focuses on adherence to plan, product ownership focuses on outcome, and how you get there is up to the team.)

The objective of the Scrum Sprint pilot is therefore to test whether or not the organization has the aptitude to adapt to this change. Undeniably, existing project managers and project management office functions will face existential crisis, and resistance is expected. And stakeholders used to fixed plan, fixed budget routines will feel uncomfortable with the seemingly indefinite nature of Scrum. This is where we Agile coaches come in: if guided well, project managers can transition into fantastic Agile transformation leaders, and stakeholders may eventually enthusiastically embrace the value creation focus and transparency that Scrum brings in.

Why “full” Scrum?

Scrum is already a “lightweight framework.” So, installing the full framework of Scrum is actually not that much work. Within the suggested 3 days preparation below, in fact, only one day is spent on training the team on the framework.

Meanwhile, there’s a systems element to Scrum, and ignoring any one part of the framework (which is comprised of Scrum pillars, values, roles, events, artifacts and rules), will not make the implementation a Scrum. It may still function, but it just won’t be Scrum (for example, just having a daily standup and a kanban board will make the team more Agile, but won’t make it doing a Scrum).

Therefore although the initial scope of this Scrum pilot may be for just one Sprint, we will still do a full Scrum implementation. No corners cut short.

Is one Sprint just enough for the pilot?

The three pillars of empiricism (evidence based management) that Scrum adheres to is:

• Transparency
• Inspection
• Adaptation

Meanwhile, the Scrum artifacts are:

• Product Backlog
• Sprint Backlog
• Increment

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that meet the Scrum Team’s current definition of “Done.” And this goes even for the first Sprint.

Therefore, from just one Sprint, we can Inspect if there is an Increment delivered, if Transparency can be observed from the Product Backlog and Sprint Backlog, and if there were continuous improvements (Adaptation) observable throughout the Sprint (e.g. Daily Scrum. Sprint Retrospective, Backlog Refinement etc.).

Of course, incompleteness and failures are expected. Yet what we want to see is aptitude, and if the Scrum Team indeed follows evidence based management, then there should be a lot we can learn from just one Sprint.

Scrum Sprint pilot timeline

Two week Scrum Sprint pilot timeline example (8 days Sprint)

(1) Product challenge and Scrum Team selection

The Scrum Sprint pilot will first start with the pilot sponsor thinking of and selecting the appropriate product challenge; i.e. what product to have the Scrum Development Team develop. Scrum is a framework that is best suited for “complex adaptive problems,” so selecting a product challenge that is, for example, complicated but not complex, will not be an effective choice for making best use of the Scrum framework.

Next, the Scrum Sprint pilot sponsor will need to think of who to put into the Scrum Team; i.e. the Product Owner (PO), Scrum Master (SM), and the Development Team (DT). This is an educational process for the Scrum Sprint pilot sponsor where he/she should seek the assistance of the Agile coach. Well trained, right mindset PO and SM selections should come before DT selection, as their input on who can be the initial DT members will be the first step of self-organization. Utmost importance should be placed on avoiding PART TIME Scrum Team members. Further, the DT will need to be a cross-functional team, and again, with no part timers. Front-end, back-end, tester, DBA, even DevOps, we would want to have all functions inclusive in the team, and people that are resourceful and motivated to broaden their skill sets across functions are highly welcome to join the team.

(2) Scrum Team training (3 days)

Teams typically go through forming–storming–norming–performing stages (Tuckman, 1965). How well the team can go through the storming stage is most critical, for if trust isn’t built and psychological safety does not emerge during this stage, teams will normalize defensively on the basis of avoidance culture and performance thereafter will be limited. The Agile coach’s objective of the 3 day training is to help the Scrum Team go through these stages rapidly, deeply, productively and positively. At the end of the day it is up to the team for what kind of team they can become. However, with the combination of effective coaching, training and facilitation, a good coach can make a big difference for the team.

The first day of the training will be spent as a refresher course on Scrum fundamentals. I like flipped learning, so will typically give the Scrum Team some prior reading (such as Gunther Verheyen’s Scrum Pocket Guide). My style is learning by doing (experiential learning) so I will do a lot of exercises, especially those that allow the teams think of “why are we doing this particular thing?” – the power of inquiry is the best medicine to mindless, heartless Scrum. Depending on the nature of the Scrum Team’s product challenge and if it’s not confusing, I may introduce some cross-discipline elements, such as Design Thinking + Scrum.

The second day of the training will be spent on team building. Again, many games and exercises intended to deepen mutual understanding, respect for diversity, and formation of team norms, language, and shared understanding. I like using LEGO? SERIOUS PLAY? for core and shared identity discovery, and a string of various team exercises from Liberating Structures for team value, vision, mission and purpose statement building. Thinking of a team name and putting together a team logo and poster is also a great shared identity building exercise.

The last day of the training is also the first day of Sprint. The DT will help the PO build the Product Backlog – in my case I may assist with a User Story Mapping exercise. Once the Product Backlog is ready, the team will proceed to Sprint Planning. Pulling Backlog Items from the Product Backlog into the Sprint Backlog, and adding details on how and what to achieve is no easy feat for the DT. The SM will facilitate and there should be a lot of clarification dialogue between the DT and PO. At the end of the Sprint Planning, the team will agree and commit to a Sprint Goal.

(3) The Sprint

Sprints are typically between one week to four weeks, with a large majority of Scrum Teams adopting a two week cycle. To keep the pilot conclude in two weeks, in this example the Sprint period is 8 days, which is rather irregular. It is up to the Scrum Team to decide the Sprint length, typically in consideration with the optimum feedback cycle with stakeholders, so after the first Sprint Review, the team can decide on the length of ongoing Sprints (if the Scrum is continuing after the pilot).

Once the Sprint starts, the DT self-organizes to maintain the pace and cycle of the Scrum. Each the PO, SM and DT will find their roles confusing, and often self-organization will dysfunction. Yet this is all part of the learning process, and over-intervention, including by the Agile coach, should be avoided. So long as there is abundant communication and close self and mutual inspection of work everyday, likelihood is that the team will continue to improve and close in with the Sprint Goal.

During the Sprint, the Agile coach will maintain a “reachable when needed” stance for the PO, SM and DT, and will check-in regularly but only lightly to see what’s going on. The coach will provide advice and impromptu training only if asked – if there is too little momentum seen from the team on continuous improvement (inspection and adaptation) the coach may nudge, but basically things will be left to the team’s self-management.

(4) Sprint Review

On the last day of the Sprint, stakeholders will be invited to attend the Sprint Review. This is the moment of truth. At the beginning of the Sprint, the PO asked the DT to build a target set of things (Backlog Items) by the end of the Sprint. Throughout the week, everyday the DT self-checked (the Daily Scrum) whether or not they are on track on building what was asked by the PO, and if there were issues, they tried to resolve it on their own, sometimes with the help of the SM. The SM helped the team stay on track, often facilitating clarification and course adjustment dialogue with the PO. The accumulation of those daily activities now result as the Increment, and if it was to satisfactory level, the PO may have released the Increment to customers. Now the PO will share the results with the stakeholders (typically accompanying a demo by the DT), and ask for feedback. If feedback is positive, the pilot may continue, so stakes are high.

(5) Sprint Retrospective

The last event of the Sprint is the Retrospective. Again, this is for the team to self-organize, but typically the SM will take an active role to foster deeper reflection among the team. I like suggesting to the SM to pick an exercise from Retromat to spice things up.

This will be also the Agile coach’s timing to provide feedback to the team on the accumulated observations throughout the Sprint. There may be a few things that deviated from the Scrum framework, and using performance related evidence, this can be a good opportunity to provide some follow on coaching and pointers for further training.

(6) Pilot review

At this point, the Scrum Sprint pilot sponsor should have enough data and information to decide whether or not to continue with the Scrum. More importantly, the findings from the pilot may provide valuable insights on the organization’s wider potential to embrace Agile. Even disappointing results from the pilot will be important information to consider. Analyzing what didn’t go well and why things did not meet expectations, may uncover hidden organizational values and priorities previously less signified. At the end of the day, Scrum needs to align with the organization’s goals or else there is no value for doing things in a Scrum way. If the Scrum Sprint pilot can help to surface and raise the awareness of those gaps, probably that itself already makes it worth doing the pilot experiment.

Cost considerations

Scrum, along with other Agile approaches, are known to have a significant J-curve effect; i.e. temporary drop in productivity before performance kicks in. Among other reason, one factor that contributes to the temporary productivity decline may come from Scrum’s encouragement for people to work in single, stable teams, rather than involving them in multiple projects. This is because in the Scrum community, we consider the cost of context switching (between different projects) is taxing to people, and it is a waste (“muda” in Lean terms) of precious brain power. Putting someone into a Scrum team nonetheless may mean pulling out that person from multiple other projects, which will affect the productivity of those projects too. This is one example of organization level costs associated to implementing Scrum. The only way to find out how costly and impactful that can be is through experimentation, hence the pilot. Meanwhile, an elongated experiment is also waste, so as starters, the limit to one Scrum Team and one Sprint for the pilot.

Regardless, Scrum is now over 20 years in existence and there are numerous statistics (e.g. Standish Group) and case studies that evidence Scrum’s significant project success rate over waterfall. If implemented well, Scrum has a clear advantage.

And yes, the caveat is, if implemented well.