Agile Transformation: Wiredrive Takes the Plunge from Waterfall to Scrum

Overview

Making the Big Move From Waterfall to Scrum

Wiredrive faced two major problems that had been years in the making. The first was that it had two competing business focuses: custom Web design; and online file-sharing services. Both provided revenues, but while the long-term potential of the latter was larger, the attention devoted to the former slowed progress on the file-sharing service. The second was difficulty in planning and implementing new capabilities for the file-sharing service. The company’s “Waterfall” process worked, but its pace and flexibility proved disappointing. Motivated by the second problem, the company decided to migrate from their existing Waterfall process, to Scrum.

The year-long transition succeeded because all company stakeholders bought into the need and sustained the commitment over the time required to work through the challenges. Wiredrive’s new Scrum process increased visibility into all aspects of software development. Surprisingly, this visibility brought new clarity to business issues, as well as to development priorities.

As a result, the company decided to re-write the file-sharing application to improve flexibility, and to terminate the custom Web design service in favor of the file-sharing business. Wiredrive adopted Scrum as a tactic to improve the company’s ability to develop software, but found that it also enabled strategic business decisions that provided major benefits. As a result, Wiredrive considers the transition to Scrum to be a success.

The Challenge

Business Focus

In the early years, Wiredrive provided a custom Web-development service, in addition to the filesharing service. The split focus impaired the company’s ability to grow revenues. While the Web-development work brought in money on a time-and-materials basis, the file-sharing business provided a continuing revenue stream that was not restricted by billable hours. The file-sharing business was more profitable, but resource contention from the other service crippled its growth.

Technical Debt from Legacy Code

Several years of development work grew the file-sharing codebase dramatically from its initial implementation. Under constant pressure to add new capabilities, the development team did so at the expense of design. The result was a codebase whose design evolved more by accretion than intent. The haphazard accumulation of “bolted on” code caused fragility. Poor design made adding new features difficult, and led to numerous defects, often in areas that seemed unrelated. Even worse, the company was unable to ensure quality before releasing the service to customers, and experienced an unacceptable level of complaints.

Unsuccessful Development Process

Wiredrive used the common “Waterfall” process to plan and execute software development. A typical Waterfall process contains the following major stages:

1. Requirements: Product Managers write requirements specifications
2. Design: Software architects or senior engineers write design documents that describe how the requirements
   are to be implemEnted
3. Execution
4. Testing and Fixing
5. Release: IT Operations deploys the application for customer use

While the process was well-defined and seemed reasonable on paper, it proved unsatisfactory in practice. The company could not deliver the desired features on anything resembling the planned schedule. Projects that were expected to take three months might take as long as eighteen.

While the process was well-defined and seemed reasonable on paper, it proved unsatisfactory in practice. The company could not deliver the desired features on anything resembling the planned schedule. Projects that were expected to take three months might take as long as eighteen.

Many factors contributed to the unsatisfactory performance:

1. Distractions from the custom Web-development service interfered with company and development focus
2. Requirements were often too big and ambitious for implementation to be practical
3. Requirements were often not well-enough defined to support estimation and implementation, and clarification caused churn that impacted the schedule
4. Even when requirements were understood reasonably well, estimates were imprecise, and work did not proceed according to the schedule
5. Scope creep and change requests disrupted the planned work, and delayed its completion
6. Software defects generated high-priority customer requests for fixes, which diverted resources from development work

As a result, the company was unable to plan and implement features in a meaningful way. Wiredrive’s customers perceived the company as unresponsive to their needs, unreliable in its promises, and unable to provide acceptable quality.

The Solution

Solving the Focus Problem

The solution was straightforward, in principle: Drop one line of business and focus effort on the more profitable one. Wiredrive’s challenges were in recognizing the degree to which the split focus was slowing progress, and having enough revenues to be able to drop the less-valuable business.

The company’s effort to improve their development process improved visibility not only into development, but with respect to business priorities. It became clear that progress in the filesharing area could only occur if the custom Web-development business was terminated.

At about this same time, the company’s financial position became secure enough that it was able to make the decision to close the Web-development business. This closure enabled the company to focus on the more profitable file-sharing business, and complete its migration to an agile development process.

Wiredrive’s President, Bill Sewell, had been hearing about the Scrum process for agile development for years. The principles of agile development sounded good. As the Agile Manifesto put it.

Bill liked the emphasis on people and results over process, and the idea that the company could become more responsive to customers. One particular agile process, Scrum, seemed particularly appropriate for the company’s needs. The challenge was in making the change happen. The Scrum process defined a particular set of practices that promised to help the company achieve this new agility, but at the cost of radically changing almost everything about how Wiredrive planned and executed its software development.

The Beginning

The first step towards a Scrum process occurred when Stefan Leikin, who managed development of the file-sharing software, attended a Certified Scrum Master Workshop. Stefan not only attended the class, but arrived early, stayed late, and took lunch-time opportunities to talk with instructor Scott Downey. Scott taught Scrum and served as Head Agile Coach for MySpace.com. He provided a wealth of practical experience in his conversations with Stefan. Stefan was sufficiently impressed with Scott that Wiredrive invited Scott to do some on-site training for members of the engineering team. Before leaving, Scott asked the students if they were excited about Scrum, or dreading it. Stefan recalls that everyone was “pumped” at the prospect of using Scrum to manage their development work.

The Plunge

One advantage Wiredrive had in making its transition to Scrum was its size: The company had fewer than forty people, and only six in the development group. Bill, Stefan, Taylor Tyng (the Product Manager), the CTO, and the development team members were unanimous in believing that Scrum was the right choice. In less than two years, all of the stakeholders had committed to the Scrum process, and the company conducted its first Scrum “Sprint.”

The Transition

The major challenges faced by the development team were in three areas: Mastering Scrum, Keeping Commitments, and Managing Technical Debt.

Mastering Scrum

While the practices of Scrum are not complex, most are unfamiliar, and learning the full set is a challenge. Scrum projects repeat their “cadence” of activities every Sprint (development cycle, two weeks for Wiredrive). Each activity must occur at its specified time, because the process is tightly choreographed. Missing any step can impact the team’s productivity dramatically.

Successful Scrum projects must go beyond learning the practices to master the choreography, until it becomes second nature. For Wiredrive, this degree of mastery occurred after about eight Sprints

Keeping Commitments

Each time the development team planned a Sprint, the team committed to a specific scope. This commitment was possible because the team knew from past experience how much work it could do in a Sprint, and estimated the amount of work needed to implement the selected requirements. Wiredrive’s metric for a Sprint’s success was whether the team implemented the planned scope. By this definition, the team had its first success in Sprint 13. This success was followed by eight failures.

Results improved gradually, until by Sprint 30 they’d had five successful Sprints in a row.

Managing Technical Debt

The fragility of Wiredrive’s software had reached the point where further development was impractical. The development team advocated “going dark” to re-design and re-implement the software, before trying to add more features. Bill describes himself as the last person who wanted to hear about the need to “go dark,” and not “shoehorn 2—3 more features to get us out in front of the marketplace,” but the team found that attempts to add more features kept breaking the application. After much discussion, the company decided to address the technical debt.

The Results

Making Sacrifices Now for Long Term Benefits

Wiredrive did “go dark.” The development team implemented a clean-sheet design to provide a platform for future development, and created extensive automated tests to enable quick assessment of product quality. This process took months, during which the company provided no new features to customers. The decision paid off, in terms of software stability and quality, and the company has been able to resume feature development with much less breakage.

Wiredrive’s transition to a Scrum development process was successful. The company is able to plan and execute software development more reliably than it could before, and while becoming more responsive to customer requests. Nine-month development cycles are thing of the past, along with the technical debt and split focus that hampered the company’s ability to move forward. More than anything else, the key contribution of the Scrum process was to make visible all of the problems, constraints, and trade-offs that could previously be ignored or deferred. The new visibility brought discomfort, as the company had to make a number of painful decisions in short order, but the benefits have been profound.

Ready to get started with your Agile Transformation? Contact us today to learn more!

 

About Cprime

Cprime is an industry-leading, full-service global consulting firm with a focus on providing integrated and innovative solutions around digital transformation, product, cloud, and technology. With over 20 years’ experience, we provide strategic and technical expertise to businesses across more than 50 industries. Our team of advisors and technical experts have the know-how to meet organizations where they are to develop actionable solutions and solve business challenges. We also collaborate with our expansive network of partners to design, deploy, and harmonize technology stacks across organizations. Our mission is to empower visionary business leaders and teams to reimagine the future of work to achieve better outcomes.

Want to share with a colleague? Download the PDF