Scrum Sprint Pilot

Scrum
Sprint
Pilot

Getting Scrum right
from the very first
attempt

Say No to Zombie Scrum

Start with a single team pilot with a full, proper Scrum implementation; no corners cut short. A half-hearted Scrum implementation will result in a dead Scrum, or worse, a dead but not dead, Zombie Scrum.

Takeshi Yoshida

Chief Coach & Founder

Agile Organization Development

Lifecycle Pte. Ltd. (Singapore)

PSM II, PSPO, Scrum.org

Bio

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 two 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 Scrum pilot will be a one Sprint at a time endeavour, 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

(1) Product challenge and Scrum Team selection

The Scrum Sprint pilot will first start with the pilot sponsor (stakeholder) thinking of and selecting the appropriate product challenge; i.e. what product to have the Scrum 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 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 Developers. This is an educational process for the pilot sponsor where he/she should seek the assistance of the Agile coach. Well trained, right mindset PO and SM selections should come before Developer selection, as their input on who can be the initial Developers will be the first step of self-organization. Utmost importance should be placed on avoiding fly-in fly-out Scrum Team members – while the Scrum Guide allows flexibility on time-commitment, daily teamwork is a requirement of Scrum and those who cannot commit to teamwork everyday cannot join the team. Further, the Developers should be a cross-functional team. 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 (2 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 training days is to be conscious of this team development dynamic, and prevent the Scrum Team from norming “mediocrely”; generating a “going through the motions” only Scrum Team is a big failure for an Agile coach. 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.

I give a Scrum crash course on the first day of training. Scrum is a light weight framework and the Scrum Guide is a mere 14 page document. However there is purpose in every element of Scrum, its rules, pillars, values, roles, artifacts and events. We spend an intensive day learning all of these elements and understanding why they exist. At each element I facilitate the team to consider what’s in for them – the power of inquiry is the best medicine to mindless, heartless Scrum.

The second day of training is for team alignment on why, what and how of the development target.
My preferred approach is to bring in Design Thinking for this day (in fact, Scrum goes very well with Design Thinking). This day is also for preparation of the Product Goal setting and Product Backlog building at Sprint Planning on the first day of the Sprint – without exception the first Sprint Planning is an overwhelming for any Scrum Team, so this day is essential for getting the team ready.

And off we go with the Sprint with Sprint Planning on day 1. It will be a wild day – getting the Product Backlog ready is already an ordeal, but from there the team needs to set a Sprint Goal and pull Product Backlog Items that will achieve the goal and place it into a Sprint Backlog, typically adding more details on what and how to achieve. The SM will facilitate and there would be a lot of clarification dialogue between the Developers and PO throughout the day. It will be exhausting, but without good planning the Developers won’t be able to focus on daily development work, so it’s an essential process for getting great results at the end of the Sprint;

(3) The Sprint

Sprints are typically between one week to four weeks, with a large majority of Scrum Teams adopting a two week cycle. It is up to the Scrum Team to decide the Sprint length, typically in consideration with the optimum feedback cycle with stakeholders. In this pilot illustration I show a two week Sprint cadence.

Once the Sprint starts, the Developers self-manage to maintain the pace and cycle of the Scrum. Each the PO, SM and even the Developers among themselves will find their roles confusing from each other, and often self-organization will have a hiccup or two. Yet this is all part of the learning process (it’s the “storming” phase), and over-intervention, including by the Agile coach, would deprive the team from the opportunity to storm and norm into a high-performance team. So long as there is abundant communication and close, mutual self-inspection of work everyday, teamwork will improve.

During the Sprint, the Agile coach will maintain a “reachable when needed” stance for the PO, SM and Developers, 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 Developers to build a target set of things (Product Backlog Items) by the end of the Sprint. Throughout the week, everyday the Developers self-checked (the Daily Scrum) whether or not they are on track on building what was asked by the Product Owner, 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 Developers), and ask for feedback. If feedback is positive, the Scrum 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. A simple “stop, start, continue” format combined with a “celebrate, learn, recognize” will nicely do the job for the first retro. For future Sprints, the team can spice things up with the myriads of retro games shared by the agile practitioners’ community.

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 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 we take things one Sprint at a time.

https://www.interfacett.com/wp-content/uploads/2012/06/001-PMP-J-curve-Leading-Change.png

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.

Would you like us to help you run a pilot? Contact us

Further reading: