An Agile Case Study - Wiredrive and Agile Development
Agile Case Study Executive Summary
In 2008, 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 in to 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.
Agile Case Study Introduction
Wiredrive provides an online file-sharing service used by creative professionals in the advertising, television, motion-picture, and interactive industries. By 2010, tens of thousands of Wiredrive users had uploaded over 3,000,000 files and delivered over 2,000,000 presentations.
A key element in the success of Wiredrive is the company’s agile software development process. Wiredrive’s Scrum process has proved effective largely because the it had the benefit of company-wide buy-in. But, as with any new process, adjusting to a new way of approaching development was challenging. In this paper, we will look at the issues the company faced, how the company overcame the issues, and how the transition has benefited the company.
The Issue
In 2008, Wiredrive was wrestling with resource contention between two successful lines of business and with software-development issues that restricted their ability to provide new capabilities.
Business Focus & Resource Contention
In the early years, Wiredrive provided a custom Web-design service, in addition to the file-sharing service. Web design was very successful, which enabled Wiredrive to incubate its file-sharing service without the need for additional investment. However, the dual focus eventually impaired the company’s ability to grow. While the Web-design 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. File sharing was more scalable, but resource contention from Web design limited its growth.
Software Development
Wiredrive had issues with technical debt and development process.
Technical Debt from Legacy Code
Several years of development work grew the file-sharing codebase dramatically from its initial implementation. Design decisions that made good sense early on became points of compromise as the overall Web services environment changed. Under pressure to add new features, the development team simply added new functions on top of the existing infrastructure. Over time, it became more difficult to extend the product. This difficulty was exacerbated by some contributions from new developers who were accustomed to different software and coding practices. The steady accumulation of code on top of a legacy infrastructure created a “technical debt” that lengthened development time and increased the number of regression bugs. Repairing those bugs extended development time even further.
Cumbersome Waterfall 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:
a. Software Engineers write the software to the design specifications.
b. QA Engineers write test cases to validate implementation of the requirements.
4. Testing and Fixing:
a. QA Engineers test the completed application and report defects
b. Software engineers fix defects.
c. The test-fix cycle is repeated until the defect level is acceptable for release.
5. Release: IT Operations deploys the application for customer use.
Most Waterfall processes share the following characteristics:
1. The project plan includes a schedule. The schedule is based on effort estimates derived from the requirements and the availability of resources.
2. The scope of requirements is large enough for the planned schedule to take several (3) to many (9+) months to complete.
While the process was well-defined, the company eventually identified a number of shortcomings that that proved difficult to address:
1. Requirements were often too big and ambitious for implementation to be practical.
2. Requirements were often not defined thoroughly enough to support estimation and implementation. Clarification caused churn that impacted the schedule.
3. Even when requirements were understood reasonably well, estimates were imprecise and work did not proceed according to the schedule.
4. Scope creep and change requests disrupted the planned work and delayed its completion.
5. Software defects generated high-priority customer requests for fixes, which diverted resources from development work.
As a result, Wiredrive concluded that the Waterfall process did not provide the predictability and flexibility that the company, and its customers, needed.
Solutions
The problems Wiredrive faced were well understood within the company. What was missing was the ability to resolve them. Starting in 2008, the company focused its efforts on resolving these problems by making two major changes.
Solution to the Focus and Resource Contention Problems
The solution was straightforward in principle: Drop one line of business and focus on the more promising one. Wiredrive’s challenges were in recognizing the degree to which the dual focus was slowing progress and having enough revenues to be able to drop the less-valuable business.
In 2008 and 2009, the company’s effort to improve their development process increased visibility into development as well as business priorities. It became clear that dramatic progress in the file-sharing area could only be made if the custom Web-design business was terminated.
Fortunately by this time, the company’s financial position was secure enough to enable the decision to close the Web-design business. This closure allowed the company to focus on the more promising file-sharing business and complete its migration to an agile development process.
Solution to the Waterfall Process Problems
Wiredrive’s President, Bill Sewell, first heard about the Scrum process for agile development around 2004. The principles of agile development aligned well with Wiredrive’s beliefs; from the Agile Manifesto:
“We value
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
— www.agilemanifesto.org
The Wiredrive partners liked the emphasis on people and results over process and the idea that the company could become more responsive to customers. One popular agile process, Scrum, seemed particularly appropriate for the company’s needs.
The challenge was making the change happen. The Scrum process defined a specific set of practices that promised to help the company achieve this new agility. But it came at the cost of radically changing almost everything about how Wiredrive planned and executed its software development.
The Beginning: Scrum Master
The first step toward a Scrum process occurred in October of 2008 when Stefan Leikin, who managed development of the file-sharing software, attended a Certified Scrum master class. Stefan not only attended the class, but arrived early, stayed late, and took lunch-time opportunities to talk with instructor Scott Downey. Scott, who taught Scrum and served as Head Agile Coach for MySpace.com, 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: Transitioning to Scrum
One advantage Wiredrive had in making its transition to Scrum was its size: The company had fewer than forty people and only eight in the development group. Bill, Stefan, Taylor Tyng (Product Manager), Daniel Bondurant (CTO), and the development team members unanimously agreed that Scrum was the right choice.
By Spring 2009, all of the stakeholders had committed to the Scrum process, and the company conducted its first Scrum “Sprint” (development cycle).
The Transition: Scrum Challenges
The development team faced challenges in three major areas: Mastering Scrum, Keeping Commitments, and Managing Technical Debt.
Mastering Scrum
The practices of Scrum are simple, but most are unfamiliar. Learning the full set is a challenge. Scrum projects repeat their “cadence” of activities every Sprint (two weeks for Wiredrive). Each activity must occur at its specified time because the process is tightly choreographed; and a missed step can torpedo the Sprint.
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 thirteen Sprints.
Keeping Commitments
Each time the development team members planned a Sprint, they 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 how much work was 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. By Sprint, 30 they’d had five successful Sprints in a row.
Retiring the Technical Debt
The rigidity of Wiredrive’s software had reached the point where further development was impractical. The development team advocated freezing the code 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 freeze the code. He said that he would have liked to “shoehorn 2—3 more features to get us out in front of the marketplace.” But the team found that the technical debt created by attempts to add more features outweighed the benefits. After much discussion, the company made the difficult decision to direct all resources to reengineering the codebase and eliminating their accumulated debt.
Results of the Scrum transition
Now past the one-year mark, Wiredrive’s experiment with Scrum is universally viewed as a success within the company. The company has observed significant benefits:
- The development team can plan work and routinely execute to the plan.
- Effective management of feature requests in the Product Backlog have banished Scope creep and change requests.
Major Findings from the Transition to Scrum
The benefits of a Scrum process are usually described in terms of customer satisfaction, which is important. However, Wiredrive learned some interesting lessons from this transition beyond issues of customer satisfaction. These findings are described below.
The Importance of Visibility
It is often said of military planning that “Amateurs study strategy. Professionals study logistics.” In other words, the most important things in a particular domain are not always the most obvious.
The same dictum holds true for Wiredrive’s discoveries about Scrum. The company found that the Scrum process
- Compressed schedules into short Sprints, which very quickly drew attention to the plausibility of the work.
- Daily tracked work at a fine-grained task level so that the current status of development was always informed.
- Forced explicit trade-offs between conflicting desires for feature development.
In short, the most important benefit of the Scrum process was the one that made all of the others possible: Visibility.
The development team members and other stakeholders quickly discovered that issues that had remained hidden or could be deferred in the past were now forced into view. The discoveries were often painful, because they required immediate action for progress to be possible. Yet it was exactly this process of discovering and addressing painful issues that made longer-term success possible.
Bill made the following observation about the change:
“In a world that is completely uncertain all the time, we can do the best job possible with the information we have control over . . . and we can roll with the rest.”
Stefan agrees, adding that transparency reduces anxiety; the “useless stupid stuff” that gets in the way of the company:
“Scrum doesn’t make everything perfect, but lays it out on the table.”
The visibility provided by Scrum played a pivotal role in other lessons learned.
The Need to Focus the Business
It was during the build-up to Scrum that the company realized how its dual focus hampered progress in the more promising file-sharing business. Terminating the custom Web-design offering was necessary if the company was to achieve its goals. While this decision was not a consequence of an existing Scrum process, it flowed naturally from the increased focus on fundamentals (visibility) that grew during the transition to Scrum.
The decision was painful, but necessary, and the benefits from the new focus followed quickly. “It was like watching the clouds part,” as Stefan put it. Distractions vanished and the company could finally devote its efforts to the area that made sense.
The Urgency of Retiring Technical Debt
Visibility played a major role in the decision to ‘retire the technical debt’ by re-writing the file-sharing infrastructure. The application’s rigidity, as well as the lack of automated testing, had made progress in short development cycles impossible. Where the previous process allowed the company to push the debt down the road, the Scrum process forced the company to make a decision about the debt.
Wiredrive decided to place a hold on new feature development and invest the time needed to re-write the application and develop automated-test capabilities.
The Value of Persistence and Buy-In
Success did not come overnight. Wiredrive’s development team required 7—8 sprints to become comfortable with the process; and about 25 before they could routinely complete work as planned. This transition took approximately one year.
During this year, the company encountered many obstacles, such as difficulty in mastering the basics of the Scrum process, coping with technical debt, and adjusting their methods to work with remote team members. Ultimately, it was the company’s persistence that made the transition to Scrum possible. This persistence was driven by the belief that Scrum would improve their ability to perform and backed by commitment from all stakeholders.
In contrast, half-hearted support and lack of shared vision among stakeholders would likely have doomed the process, leading to the worst of both worlds: A failure to improve and wasted effort from the attempt. Wiredrive avoided this fate by achieving stakeholder buy-in across the company before starting the migration to Scrum.
The Lessons of Failure
The Scrum process emphasizes learning from experience, by making retrospective meetings part of the process. The lessons learned relate mostly to tactical and developmental issues, which help the development team to improve over time.
Wiredrive also learned a strategic lesson about Scrum: it is not always the right process.Encouraged by the improvements in software development, the company tried to implement Scrum in their sales process.
The company was surprised to find that a Scrum process that had worked well for software development did not prove effective for managing the sales process. Standard Scrum metrics, such as tracking “Stories done” and “work remaining,” were not very useful for a sales process. Instead, after five iterations, the company evolved a “Swarm” strategy, which relies on tracking sales stages instead of Scrum tasks. This approach proved to be more effective.
Scrum Tools and Techniques
With a small group of people in one office, Wiredrive was able to start with a co-located team, and use whiteboards and corkboards to plan and track progress. Some modification was required over time to enable effective collaboration with a developer, the Product Owner, and the CTO who were not in the same office as the rest of the team.
Planning
Wiredrive uses the following tools for planning:
- Scrum Board (large cork board with swim lanes)
- Story Cards (half-sheets of paper printed with a Scrum story template)
- Task Cards (index cards)
- White Board
- Pens/Markers
- Poker Chips (for story estimates)
- Masking Tape
- Burndown Chart
- Scrumy (an online Scrum board for those to view outside of the office, www.scrumy.com)
Taylor, the Product Manager, is responsible for writing requirements in the Scrum “Story” format on story cards. The development team kicks off each Sprint by estimating the size of the top-ranked Stories, selecting a set to be implemented in the Sprint, and creating a list of tasks (the task breakdown) for each Story. The task breakdown contains all tasks that are large or significant enough to be worth tracking, and whose execution implements the requirements. The team members write these tasks on index cards.
Figure 1 - Storycard example
Tracking
Tracking and Planning are closely related; both involve the same set of index cards. The Story and Task cards are tacked onto a corkboard, which is divided into columns labeled “Not Started,” “In Process,” “Ready for Review,” “Done,” and “Impeded.” During Sprint execution, the team member who starts or completes a task moves the task card to the appropriate column. Thus at any time, the “Scrum board” displays the current status of all tasks planned for the Sprint.
Figure 2 - Production Scrum Board
The production scrum board is a series of 3 large corkboards mounted vertically and combined together to ensure enough physical space for 2 weeks worth of priorities and index cards. The team used twine as the divider lines to help delineate the rows.
Figure 3 - Final Burndown Chart
Wiredrive’s burndown chart explains the pacing of the development team over time and notates found or adopted points. Code deploys are listed on the bottom of the Sprint Commitment Line timeline. Sprint burndowns are created in Apple’s Numbers application, which makes point tracking and chart design easy.
Collaboration
Scrum emphasizes collaboration and self-organization among team members, both of which occur constantly at Wiredrive. Team members call their own meetings, hold impromptu whiteboard design sessions, and do pair programming. All activities are done on their own initiative.
Tools initially used for collaboration included only whiteboards, corkboards, and the usual office applications (email, spreadsheets, word-processor documents). After the first several Sprints, however, it became clear that with one team member in Morocco that the company needed to make Scrum work in a distributed environment. They responded to this need by implementing three key changes:
1. They required that the remote team member keep “California hours,” working at the same time as the rest of the team.
2. They used an inexpensive “electronic Scrum board,” Scrumy.com, to track requirements and work status. This change resulted in some duplicate effort, as the same tasks are tracked on both the corkboard and Scrumy.com. Wiredrive has found this degree of redundancy acceptable to date.
3. They used electronic communications tools, such as iChat and conference calls, to provide as much real-time communication between distributed personnel as possible.
These changes made distributed development workable.
Conclusion
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, while becoming more responsive to customers. Nine-month development cycles are a thing of the past, along with the technical debt and dual 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 it forced the company to make a number of painful decisions in short order, but the benefits have been profound.
