This experience report describes how a well-intentioned ‘mechanical’ implementation of scrum did not deliver on promise of agility, and why a Scrum Reboot with values has. It describes how a focus on the Scrum Values of Courage, Focus, Openness, Respect and Commitment provides the cultural environment necessary for success. Intralinks made the values real by focusing on seven principles of self-organization, 7 +/- 2 team size, done means done, empowered product owners, servant leader Scrum Masters, team ownership for adaption and the delivery of business value. And how the fundamental idea of inspection and adaption, a cornerstone for Scrum was made real.
1. INTRODUCTION
This experience report tells the story of how a mechanical implementation of Scrum—done in good faith and with lots of hard work—failed to deliver agility, and how a ‘Scrum Reboot’ succeeded by augmenting the mechanics of Scrum with its values. The events, roles, and artifacts of the Scrum framework are necessary but not sufficient for a successful change. With the Scrum Reboot, Intralinks looked at the Scrum framework, paid close attention to its principles, and in so doing successfully took on its values. Only with this deeper adoption of Scrum did they start seeing signs of real Agility.
2. Background
Five years ago Intralinks decided to adopt Scrum. As a SaaS provide of virtual data rooms for the M&A industry seeking growth opportunities by modernizing their user experience and extending their platform to address adjacent use cases, Intralinks needed to:
- increase product development scale,
- decrease lead times to delivering business value,
- improve quality,
- and, of course, attract talent.
Their research on Agile development practices indicated that Scrum was the way to go. Scrum was widely adopted and there were numerous examples of successful implementations with great results.
Intralinks planned a conventional approach: first, train everyone in Scrum, next, coach them through its adoption. After all, it’s just another software development methodology, and that is how methodologies are introduced.
3. Scrum: Hold the Values
Except Scrum is not a methodology. It is a lightweight framework that neither requires nor is necessarily incompatible with other tools, tactics, processes, and methods. Here’s the rub on Scrum: it is a framework (the ‘easy to learn’ part) that will not deliver on its promise unless it is exercised with its core values (the ‘hard to do’ part).
And that is what Intralinks saw the first time they gave Scrum a try. Far from unique to Intralinks, this failed adoption is a common phenomenon (and it sometimes takes years before anyone realizes they got it wrong).
But the importance of Scrum values is right there for everyone to see.
“When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.” —The Scrum Guide
Let’s look at the symptoms Intralinks observed when the Scrum framework was implemented without successful adoption of Scrum values.
3.1 Commitment: We Don’t Need No Stinking Sprint Retrospective!
“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next sprint.”—The Scrum Guide
The Sprint Retrospective provides the Scrum Team with the opportunity to review how they are working, identify issues and make decisions about how they can improve. Even if the team sticks to the framework, respects the roles, and maintains the artifacts, they will always have the opportunity to improve by learning from their missteps.
Taking action to improve, however, is hard. At Intralinks when the team closed out their Sprint Retrospective and headed into Sprint Planning, they were taking on new work in their Sprint Backlog but they were not committing to improve. The pressure to get work done pushed the desire to improve to the backburner. They might occasionally take on improvements under their control, but others requiring external support were dropped because of a lack of commitment from the organization.
Under these circumstances, the value of the Sprint Retrospective was nominal. Inspect and adapt became inspect and complain, and then eventually inspection ceased entirely.
3.2 Courage: The Sprint Report?
“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint … This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.” —The Scrum Guide
During a Sprint Review the team puts the result of its work under the spotlight for stakeholders to provide feedback. Team has to present the increment and review the backlog with transparency. Stakeholders have to provide honest feedback. Without this the benefit of inspection and adaptation fades. Properly executed, however, the team must have the courage to underwhelm, disappoint, or even upset stakeholders (openly and with respect of course).
But at Intralinks the team lacked courage so they set up the Sprint Review for success. The Sprint Review turned into a Sprint Report: here’s how much work we did; here’s what our burndown looked like; this is how many defects we found and fixed. The team took credit for having worked hard whether or not that hard work generated business value. Stakeholders’ eyes glazed over and after a while stopped attending. Remaining participants were managers instead of stakeholders.
3.3 Focus: Daily Scrum for Everybody?
“The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet its Sprint Goal.”—The Scrum Guide
The Daily Scrum, properly executed, epitomizes focus. The scrum master only attends to ensure it happens and serves its purpose. The product owner stays out of the way. It is a short meeting, always at the same time and place—the Development Team gets the Daily Scrum into muscle memory. It is the Sprint’s heartbeat.
But at Intralinks, lacking focus, the Daily Scrum grew. It moved around, it skipped some days. Project and program managers showed up because it was a convenient way to check in on the team’s progress. The Scrum Master started to drive the meeting and instead of a half-circle around the sprint board inspecting the work, it became a half-circle around the Scrum Master with rapid fire status reporting. Team members were engaged for the 45-60 seconds they spoke then they tuned out.
Instead of epitomizing focus, the Daily Scrum became a 15-minute distraction.
3.4 Openness: The Scrum Manager?
“The Scrum Master is responsible for ensuring Scrum is understood and enacted … The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”—The Scrum Guide
We’ve seen this everywhere. The product development organization adopts Scrum and the team leads or managers become Scrum Masters. Conventional wisdom suggests they are the most qualified, they have experience as leaders, and through training they will be able to adjust to the role easily enough. In fact, managers are frequently ill-suited for the role.
At Intralinks, the manager-turned-Scrum-Master took on the new role in good faith, but it resulted in a lack of openness in the team. The Scrum Master occupied the same hierarchical position in the organization, reporting to a director or VP. These upper managers had not had the same exposure to Scrum and still expected the Scrum Masters to manage the work. Put differently, they held the Scrum Master accountable when the work wasn’t happening the way it was supposed to. So even if the Scum Master was liked by the team and if behind closed doors the Scrum Master was reasonably good at being a servant-leader instead of a manager, the team closed up and put on a good face for the organization. They hid failures and therefore what should have been a self-organizing team lost the opportunity to improve.
3.5 Respect: The Product Steward?
“The Product Owner is the sole person responsible for managing the Product Backlog … For the Product Owner to succeed, the entire organization must respect his or her decisions.”—The Scrum Guide
The Product Owner must be given, and must be capable of wielding the power to control the destiny of the product. For each product there is a single Product Owner. It takes tremendous maturity, and requires organizational backing at all levels. Ironically, where Scrum Masters are often selected from a pool of experienced engineering managers, Product Owners are often fairly junior product managers. The ‘real’ product managers don’t have time for product ownership.
At Intralinks, the Product Management was—as in many technology driven companies—very much a technical product management organization—responsibility for implementation, but very little business ownership. Product decisions were made by upper management (with considerable influence by engineering). As a result, the Product Owners were given the title but remained in the service of the product as its steward rather than its owner. When the team came to the ‘Product Steward’ with an issue requiring a decision, he or she retreated into email, meetings, and conversations. More often than not the answer did not come back before the sprint ended, if it came back at all.
With the ‘Product Steward’ consistently unable to resolve issues in a timely manner, the team in some cases just stopped bothering to ask. The team perceived the Product Owner not having the respect of the organization, the team similarly lost respect for the Product Owner.
4. Clearly, Scrum Does Not Work
There were some early wins and enthusiasm when Intralinks first started their transition to Scrum. Change of any kind is an energizer. and some teams adopted Scrum and it obtained some good results—better collaboration between team members and better communication on progress to stakeholders via Sprint Review.
But the wins were modest and the enthusiasm declined. Scrum was a different vocabulary and set of behaviors wrapped around what Intralinks had been doing all along. Employee engagement surveys reported the same issues Scrum was brought into help resolve: lack of clarity in decision-making; frequent disruption from upper management; no sense of ownership; reporting good progress in bad faith to avoid the ineffective interventions by management.
So when Intralinks took a closer look at what had gone wrong with Scrum, they came to what may seem like a surprising conclusion:
Let’s try Scrum!
It was clear that it was not in fact Scrum that was failing, but rather that the adoption of Scrum was superficial and lacked the values without which Scrum fails to deliver on its promise.
5. Scrum Principles: The Bridge to Scrum Values
The values part of Scrum is hard. It’s not obvious how to get people to behave according to a set of values. The more you push values on someone the more likely they are to reject them. A coach shouting at the team: ‘commit to inspection and adaptation‘; ‘have the courage to review the sprint with transparency!’; ‘use the daily scrum to focus on the work in the sprint, not your respective statuses!’; ‘be open about how hard it is to adopt Scrum with your Scrum Master!’; ‘respect the authority of the Product Owner even when the CEO barges in!’—is not likely to obtain good results.
With the strategic decision to reboot Scrum came the tactical decisions to re-invest in training, but also to inspect and adapt based previous attempt to adopt Scrum. They needed the organization to take on Scrum values, but because these are so hard to teach, they decided to focus on Scrum principles—the hypothesis was that successful adherence to the principles would lead to adoption of the values.
But what are Scrum principles? Unlike the three pillars of Scrum (transparency, inspection, and adaptation) and its five values (commitment, courage, focus, openness, and respect), Scrum principles are not so explicitly called out in the Scrum Guide. Perhaps they should be.
The principles sit between the framework (a fairly ‘hard’ set of events, roles, and artifacts) and the values (‘softer’ behavioral attributes). For example, you can easily hold a Sprint Retrospective at the end of a sprint in the appropriate timebox, but if the team does not take ownership of adaptation (as opposed to mere inspection) nothing will ever improve.
We identify seven principles:
- Self-organization
- Team size and composition
- Done means done
- Empowered Product Owners
- Servant-leader Scrum Masters
- Team ownership of adaptation
- Delivery of business value
Not getting traction on these principles is a leading indicator that the corresponding values are not guiding the behavior of the team (and usually the whole organization). Having a conversation to rally around these concrete principles will encourage the increased adoption of the softer values.
5.1 Self-organization
Fundamental to Scrum is the ability for a team to self-organize: to take on work, make a plan to complete the work, and execute that plan. For an organization moving away from a legacy where managers managed the work, this is very difficult to do. It means that some people have to stop doing what previously defined them professionally, or that they need to do it as part of a team without the authority that organizational structure would have previously given them.
For Intralinks, taking on the principle of self-organization led to a genuine sense of ownership of the work. Because the organization let the team self-organize, the team felt that it had the respect of the stakeholders. Although this had effects in Sprint Planning and all the way through the Sprint, a key change was that the team ended up having the courage to bring greater transparency to the Sprint Review. It evolved from a candy-coated progress report to a mutual commitment (team and stakeholders) to have a conversation about the business value of what was just delivered and what was planned next.
5.2 Team Size and Composition
The principle of team size and composition is quite specific: between 3 and 9 people, and consisting of all the skills necessary to do the work required of the team to produce done software. This principle follows directly from the principle of self-organization: the team has to right-size itself and figure out if it can produce software according to its definition of done. If team size and/or composition is not right, something has to change. The change may be within the team’s control (e.g., skills and training), but it may not (e.g., they need additional team members) in which case they bring the issue as an impediment that the Scrum Master can help remove.
For Intralinks, taking on the principle of team size and composition meant the team had to commit to taking on the work, and also had to have the courage—if it were the case—to tell management that they could not do so. The Scrum Master did not unilaterally decide who was on the team or who needed to be added, he or she was open to giving the team the space they needed not only to assess their deficiency in terms of team composition, but to propose solutions that he or she could help make happen.
5.3 Done Means Done
Although the Definition of Done itself evolves over time, the principle of done means done is static. The team takes ownership of a specific Definition of Done and only shows work done in a sprint that meets the definition.
For Intralinks, the Product Owner role evolved from Product Steward to Product Owner. It was not easy for stakeholders accustomed to getting their way, and it was not easy for all Product Owners to take on the responsibility of making decisions and being accountable for them. Stakeholders learned to respect the Product Owner and the Product Owner developed the courage to take ownership of the product. Over the course of several sprints it was not uncommon for a Product Owner to call out a stakeholder in front of the team, and at times the team would call out the Product Owner for avoiding some hard choices. But with openness, mutual respect, and a commitment to getting the work done now (and then measuring it against its anticipated business value later), everyone learned that over the long haul Scrum, through its framework, principles, and values yields better results.
5.4 Scrum Master as the Servant-Leader
While the role of the Scrum Master as the team’s own Scrum expert and remover of impediments is self-explanatory, the less obvious principle of servant-leadership is required to be an effective Scrum Master. The Scrum Master does not manage the team or the work. In fact the Scrum Master shouldn’t even manage the adherence to Scrum. Instead, the Scrum Master observes the team and reacts to deviance from the Scrum framework as an opportunity to ask the team why it’s happening. The Scrum Master sees difficulty to adhere to Scrum principles as a signal for inspection. The Scrum Master sees failure to behave according to Scrum values as points of more significant intervention. Where the manager’s instinct might be to correct deviation from a goal the moment it occurs, a Scrum Master may choose to see where it goes and give the team an opportunity to self-correct.
For Intralinks, the earlier attempts to fill Scrum Master roles with managers perpetuated hierarchies that were incompatible with the principle of self-organization, and resulted in ‘Scrum Managers’ instead of Scrum Masters. Sprint Planning couldn’t start until the ‘Scrum Manager’ showed up. The Scrum Manager would decide which actions to take following a Sprint Retrospective (or in some cases unilaterally decided that in the next sprint getting work done was more important than improving). It was a courageous move to train in-the-trenches developers, have them obtain PSM I, and then take on the Scrum Master role. When the corresponding managers backed away, stopped managing the work, this demonstrated respect for the team.
Interestingly—and this is still a work in progress at Intralinks—a manager’s role changes dramatically when they are no longer called up to manage the work. Instead of constantly tracking progress against a project, they produced progress metrics after every print that the team then used to judge whether any changes were required. Like the Scrum Master, they served the teams by supporting improvement initiatives proposed by the team, for example addressing team composition changes or pursuing training/learning opportunities.
5.5 Adaptation requires ownership
The three pillars of Scrum are transparency, inspection, and adaptation, but the driving principle behind this empirical process control is that the team takes ownership of adaptation. The team owns the responsibility to improve based on empirical learning. Management may assess team performance and may be required to facilitate adaptation initiatives (e.g., provide budget for training, equipment, or increasing team capacity by adding members to the Development Team), but the team, by virtue of the principle of self-organization, is on the hook for coming up with improvement proposals.
For Intralinks, the once neglected Sprint Retrospective took on renewed importance and energy. Teams would maintain an explicit improvement backlog and took on at least one improvement backlog item per sprint. The Sprint Retrospective (especially when previously run by the ‘Scrum Manager’) had previously been perceived as a burden, imposed upon the team by management. Only when the principle of owning adaptation was taken seriously did the Sprint Retrospective become an opportunity to improve. This in turn promoted commitment by the team to improve, and openness by the team to speak constructively about what did not work well in the previous sprint.
5.6 Delivering Measurable Business Value
Scrum adoption can lead to improved morale, tighter communication, less technical debt, more frequent releases—but if the end result doesn’t deliver business value there’s not a lot to cheer about (at least not for long). This last principle, delivering measurable business value, is the most important one. However, that does not mean that you should prioritize it over the others. Instead, you need to understand that adherence to the other principles combined makes the probability of successfully adhering to this principle much higher. When the backlog is refined and work is taken on in a Sprint Backlog, it must be accompanied by some hypothesis about the value it will deliver. This value must be expressed in a way that is quantifiably measureable after it is released, and tracking against that metric is required.
For Intralinks, this added a new responsibility for the Product Owner. Previously backlog items were primarily features, and prioritization was primarily a war of opinion, and the Product Owner was on the receiving end. Taking this principle more seriously, the Product Owner had to justify priorities with hypotheses about net new business, increased adoption, improved positioning against specific competitive offerings, and/or cost savings. The Product Owner was not expected to accurately predict the outcome, but rather to make a case and provide a means by which the actual result could be measured against what had been forecast. The fact that the Product Owner had the respect of the organization to describe the business value in measurable terms gave the team focus as they implemented the corresponding solution, and the entire organization thereby commited to assess the actual value of the work once shipped (as opposed to fire-and-forget).
6. Results
Having read this experience report it may seem like Intralinks has already completed a 100% successful reboot of Scrum and is now cruising along, crushing Scrum and delivering measurable business value every sprint. Not quite. The Scrum Reboot has had successes with some teams and struggles with others. Adoption at the management tier similarly has peaks and troughs. But compared to the first attempt (where ironically adoption seemed easier even though it did not obtain the expected results) the renewed effort which pushes the principles in order to encourage the adoption of Scrum values is resulting in the expected benefits where real change is occurring.
In particular, one large project involving a complete re-implementation of the Intralinks Platform’s UI has gone from a monolithic release plan to a rolling program releasing updates almost monthly. Accumulation of technical debt previously deferred to hardening phases has been eliminated. Sprint Planning became the venue for the team and the team alone to take on and plan work to be completed in the Sprint. What had been a very large ‘Scrum’ team run by a single ‘Scrum Manager’ was recomposed into two smaller teams (with designers integrated into the team) resulting in lower running costs for the project and greater velocity. The teams nominated a ‘Done Champion’ for the first few sprints and committed to a Definition of Done that evolved from learnings in those sprints. The Product Owner, while not particularly senior in the organization, is the undisputed decision-making unit with respect to the Product Backlog. The Scrum Masters (who are also Development Team members) are servant-leaders that are not responsible for managing the work, and do not have any direct reports on the teams. The Sprint Retrospective is held religiously and the teams maintain an improvement backlog that they act on every sprint. Lastly, the Sprint Review showcases done software. They are lively conversations with stakeholders, and are a transparent review of the anticipated business value. Post-release updates on business value metrics are shared with transparency, usually indicating positive adoption, but occasionally indicating a misfire, and resulting in de-investment where the hypothesis put forward by the Product Owner proved wrong.
7. What We Learned
If Scrum adoption seems easy, you are almost certainly not adopting is correctly. You are probably going soft on its principles and therefore the teams and supporting organization are not living its values. When this happens things change on the surface but outcomes are the same. Scrum adoption with its values is not only hard at first, it keeps on being hard. Maybe it gets a little easier after some time (Intralinks is not there yet) but it is almost certainly going to remain a hard thing to do.
Developing software is complex. A complex project with multiple people is going to be challenging. Scrum won’t make it easier. It will simply give you a framework, principles, and values that make the hard work much more likely to result in positive business outcomes.
For Intralinks, the key difference with the Scrum Reboot compared to their first attempt to adopt Scrum was to get to Scrum values. Initially, how to jump from the Scrum framework to Scrum values was not obvious. It did not seem like Scrum coaches and Scrum Masters shouting ‘respect!’, ‘commitment!’, or ‘focus!’ would have a meaningful impact. But in looking closer at the Scrum Guide, Scrum principles appeared to be the right balance of things teams and individuals could concretely act on, and that doing so would naturally encourage the corresponding values.
8. Acknowledgements
The Scrum Reboot has taken the hard work of many people throughout the Intralinks organizations. In fact, everyone on a Scrum Team or supporting a Scrum team should be acknowledged for their hard work, and perseverance. It would have been very easy to discount the reboot as just another waste of time.
The Scrum Reboot required some back to basics, experience driven training which was delivered by Professional Scrum Trainer Ben Day. He did an amazing job of reminding us all that Scrum is an empty thing without values and focus on Done. Thank-you Ben.
We would also like to thank David Grabel, our experience report Shepherd who helped remind us of the time box and encouraged our endeavor. Also, Rebecca Wirfs-Brock who not only helped format, structure and present the experience report, but also has a special part in the history of Scrum being the track chair that accepted the first Scrum paper at OOPSLA 1995.
REFERENCES
Schwaber, Ken, and Sutherland, Jeff, The Scrum Guide, scrum.org, July 2016 Version
Copyright 2017 is held by the authors.
