Five Things Every Software Executive Should Know About Scrum

Transcription

1 B E S T P R A C T I C E S W H I T E P A P E R Five Things Every Software Executive Should Know About Scrum Jenny Stuart, Vice President of Consulting, Construx Software Version 1, May 2012 Contributors Jerry Deville, Senior Fellow Melvin Perez, Senior Fellow Scrum is an approach for Agile software development and is the most commonly adopted Agile approach in the industry today. This paper explores five important things software executives should understand when their organization is considering adopting the approach. It includes information about what Scrum can and cannot provide, and advice for how executives can support the adoption of Scrum. This white paper was downloaded from

2 Contents Contents... 2 #1 - A Majority of Agile Teams Are Using Scrum... 3 #2 - Scrum Offers Multiple Benefits... 3 #3 - Scrum Is Not a Cure-All... 5 #4 - Scrum Does Not Solve All Problems... 6 #5 - Scrum Is Successful in Diverse Environments... 7 Advice for Software Leaders... 8 Contributors... 9 About Construx Best Practices White Paper 2

3 #1 - A Majority of Agile Teams Are Using Scrum Scrum is a team-level workflow process for Agile software development and is the most commonly adopted Agile approach in the industry today. It is part of the movement and methodologies resulting from and continuing since the Agile Manifesto, 1 which was published in Agile methodologies were initially developed to be responsive to change. Early adopters were typically organizations with volatile business requirements and in which the end state of the development effort was fluid. Since then, Scrum has been adopted widely in numerous software/systems development organizations. The 2008 State of Agile Development survey 2 reported that over 71% of teams using Agile are using some variation of Scrum and approximately 8% are using XP. No other method accounted for more than 5%. It is Construx s opinion that Scrum has crossed the chasm. 3 Today, many organizations are using Scrum in more stable situations, on large projects, and on cross-geography projects and organizations. If effectively adopted, Scrum helps them achieve the balance of predictability and flexibility that supports the business needs well enough to make customer commitments. #2 - Scrum Offers Multiple Benefits Many organizations are interested in Scrum but wonder what value it can bring to the development organization and to the business. Construx s clients have found that Scrum can enable the adopting organization to do the following: Insert high-value features, even late in the development cycle. In the waterfall software development model, all work was completed sequentially. As shown in Figure 1, this resulted in organizations having limited working software until the project was nearly completed. In other words, the business did not realize any of the benefits or value of the project until it had expended all or almost all of the cost to build it. 1 Agile Alliance, Agile Manifesto, (2001) 2 VersionOne,3 rd Annual Survey: 2008 The State of Agile Development, Agile Chronicles (2008) 3 Geoffrey A. Moore, Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Harper Business Essentials, Best Practices White Paper 3

4 Figure 1 Traditional Project Value Delivery In contrast, Scrum enables organizations to realize the benefits of the project throughout the development cycle. As shown in Figure 2, a project that delivers the functionality based on its business priority actually sees diminishing returns later in the project as the highest value functionality is already completed. Figure 2 Scrum Project Value Delivery This dynamic enables a project outcome like the one shown in Figure 3. On this project, the organization inserted new features late in the project that had higher business value than the features previously planned for delivery. Figure 3 Scrum Enables Delivery Opportunity Respond to a dynamic marketplace. Scrum has frequent iterations, explicitly orders the work to be completed, and brings the completed work to a potentially releasable state. This ensures the functionality delivered to date is close to something that can be released to customers. It provides numerous points in time where higher value customer requests can replace lower priority work already in the queue. In highly dynamic markets, the final feature set delivered to market can be radically different Best Practices White Paper 4

5 and of greater business value from what the organization initially thought of delivering. Have ground-truth-based progress visibility. Historically, progress in the waterfall life cycle was often monitored by the completion of requirements specifications, design documents, and other activity-based progress. In contrast, Scrum projects are monitored by how much functionality has been accepted as complete by a customer representative. This provides clearer visibility into the quality of the functionality delivered to date. This leads to greater visibility into schedule and delivery risk than in other methods. Incorporate customer feedback earlier. The frequent iterations of Scrum provide numerous opportunities to demonstrate, beta, preview, or otherwise expose the customer base to new features throughout a project. In some cases, the customer feedback often occurs during each Sprint because customers can participate in the demos. In other cases, the Product Owner or marketing representatives gather feedback as major features are completed or on a regular heartbeat. Whatever the cycle, Scrum enables more frequent demonstration of working functionality. End a project early with delivered value. With incremental delivery, organizations have the option to end a project early and ship with the functionality delivered to date. Beyond these benefits, Construx has also seen organizations where Scrum adoptions helped to drive improvements in product quality and software development productivity. #3 - Scrum Is Not a Cure-All As a result of Scrum s popularity, there is significant discussion in the industry about what Scrum is and what it is not. In Construx s opinion, it is important that executives understand that Scrum is not the following things: A goal in and of itself. Organizations move to Scrum because they perceive it can bring benefits to the business. For some organizations, it s the ability to rapidly respond to a changing marketplace. For others, it s the improved project predictability that comes from continuously delivering near-production-quality software. When adopting Scrum, the executive team needs to understand and communicate what it wants to improve by moving to Scrum. Because of Scrum s history as an approach that responds rapidly to change, development teams can believe that flexibility is what the business wants. In many cases, the business doesn t want to trade predictability for flexibility. It is important that everyone is on the same page with regard to the goals. An ad hoc development methodology. Scrum is an approach to managing the toplevel workflow at the team level. Scrum is not something that works without effort and discipline. Teams need to create a Definition of Done that provides explicit Best Practices White Paper 5

6 quality criteria for completing work, they need to bring the product/system to nearproduction quality every two to four weeks, they must establish mechanisms to provide visibility into the Sprint and the progress of the release, and so forth. Organization-wide adoption of Scrum requires training and coaching to ensure that all teams are making effective use of the approach. Work is needed to ensure that large projects communicate, coordinate, and distribute requirements effectively. A Silver Bullet. While some teams have seen significant productivity gains when adopting Scrum, some organizations report only minimal changes in productivity. Scrum, instead, provides them with the ability to respond to a changing marketplace, improved product quality, feature-set visibility, or other benefits discussed elsewhere in this paper. An excuse for poor practices. Scrum is not an excuse for code-and-fix programming, justifying bad practices, or removing the need for all documentation. When Scrum is adopted, teams need to ensure their development practices (code reviews, Test Driven Development, automated unit testing, continuous integration, etc.) support the frequent delivery cycle. An excuse not to document. When adopting Scrum, the organization needs to determine what documentation is no longer needed. For example, are Product Requirements Documents, Functional Requirements Specifications, and other such items replaced by a product backlog or similar Agile artifact? These changes streamline the development process. The organization also needs to ensure that any required documentation (architecture specifications, release notes, test cases, and other items) needed for compliance, effective long-term development work, internal governance, or other reasons are incrementally produced. #4 - Scrum Does Not Solve All Problems Ken Schwaber, one of the creators of Scrum, stated, Scrum exposes every inadequacy or dysfunction within an organization s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. 4 Construx s experience is that, when used as a team-level workflow method, Scrum does not in and of itself solve larger organizational-level issues. The major issues that need to be considered when adopting Scrum are that Large projects and organizations need more structure than small teams. A teamlevel workflow method works well for individual teams or even small sets of teams working together in a single location. Today many organizations are scaling Scrum to large teams, teams of teams, and significant geographic and/or time zone distribu- 4 Agile Collab, Interview with Ken Schwaber, (2008) Best Practices White Paper 6

7 tion. This requires the organization to put in place infrastructure and practices beyond Scrum. Good requirements still require focus and expertise. Scrum often changes the way organizations capture requirements. For example, they begin to create user stories, estimate them using story points, and capture them in an ordered product backlog. Although the specific techniques change, moving to Scrum does not ensure that highquality requirements are provided to the teams. For example, an organization with challenges in understanding, synthesizing, and selecting the most important requirements across a diverse marketplace will continue to have the same issues after the teams have moved to Scrum. However, the move can be a good catalyst for making changes in these areas. For example, focused training of Product Owners can occur during the Agile transformation. The organization can also put in place a Chief Product Owner to establish a vision, create a product roadmap, and manage the toplevel backlog for its large products. Appropriate long-range business planning is needed. Highly effective projects understand the direction they are heading in. For some projects, it is a move toward innovation and experimentation. For others, the goal is to bring a particular feature set to market. Moving to Scrum does not change the need for appropriate long-range planning. Most organizations still need product visions, product roadmaps, and Agile release plans. These artifacts provide the larger picture in which Scrum operates. They provide a context for ordering the backlog, making tradeoff decisions, deciding when to pay down technical debt, and so on. As part of the change to Scrum, an organization needs to monitor the issues that arise and make explicit decisions about what it wants to change to support more incremental and iterative development. It needs to make decisions about how Scrum fits within organizational constraints such as compliance requirements, the inability to change the working processes of other parts of the organization, and so on. For more information, see Construx s 7 Pitfalls to Enterprise Agile Adoption, Distributed Scrum, and Managing Technical Debt white papers. #5 - Scrum Is Successful in Diverse Environments Scrum has proved to be flexible and adaptable to diverse settings. It is being used successfully in the following situations: Very large projects and multiproduct organizations Geographically dispersed teams Commercial, internal, scientific, and embedded systems Mission-critical and life-critical applications Regulated industries (for example, industries regulated by the SEC, FDA, and FAA) Best Practices White Paper 7

8 Organizations with stage-gate product development models and with PMOs The success (or failure) of Scrum is all in how it is adopted. For more information, see Construx s 10 Keys to Successful Scrum Adoption, Optimizing Agile for Your Organization, and 7 Pitfalls to Enterprise Agile Adoption white papers. Advice for Software Leaders Executive-level support is helpful for all change efforts. You can help the transformation to Scrum in the following ways: Learn more about what is necessary for a successful transformation. Numerous books on Scrum have been published and Construx s Scrum white papers are all useful resources. Understand and explicitly state the goals for the change to Scrum. Determine how Agile your organization will be (iterating from the requirements onward, using Scrum during the development phase only, etc.). Allocate funds for all necessary resources (typically, training and coaching) to support the transformation. Ensure a customer representative is available to Scrum teams. Validate that the new project-reporting techniques provide the necessary visibility into project progress. Ensure that the current rewards and recognition structure doesn t undermine the move to Scrum. Support the organization s transformation as requested by the staff throughout the change. Please contact us for further discussion regarding executive-level concerns in order to make your transition as successful as possible. Construx is happy to provide more information as appropriate. Best Practices White Paper 8

9 Contributors Jenny Stuart, VP Consulting +1(425) Steve McConnell, CEO, Chief Software Engineer +1(425) Jerry Deville, Senior Fellow +1(425) Melvin Perez, Senior Fellow +1(425) About Construx Construx Software is the market leader in software development best practices training and consulting. Construx was founded in 1996 by Steve McConnell, respected author and thought leader on software development best practices. Steve s books Code Complete, Rapid Development, and other titles are some of the most accessible books on software development, with more than a million copies in print in 20 languages. Steve s passion for advancing the art and science of software engineering is shared by Construx s team of seasoned consultants. Their depth of knowledge and expertise has helped hundreds of companies solve their software challenges by identifying and adopting practices that have been proven to produce high-quality software faster, and with greater predictability. For more information about Construx s support for software development best practices, contact us at consulting@construx.com, or call us at +1(866) Best Practices White Paper 9

10 2012, Construx Software Builders, Inc. All rights reserved. Construx Software Builders, Inc NE 8th Street, Suite 1350 Bellevue, WA U.S.A. This white paper may be reproduced and redistributed as long as it is reproduced and redistributed in its entirety, including this copyright notice. Construx, Construx Software, and CxOne are trademarks of Construx Software Builders, Inc. in the United States, other countries, or both. This paper is for informational purposes only. This document is provided As Is with no warranties whatsoever, including any warranty of merchantability, noninfringement, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification, or sample. Construx Software disclaims all liability relating to use of information in this paper.