Improving Business Outcomes with Agile Discovery and Development by John Parker, CEO Contact Us: 210.399.4240 info@enfocussolutions.com Copyright 2014 Enfocus Solutions Inc. Enfocus Requirements Suite is a trademark of Enfocus Solutions Inc. All Rights Reserved. March 2014
Agile software development has gone mainstream. It is rapidly becoming the de facto standard software development process, and the main question for software managers and executives is no longer Are we going to adopt agile? but when and how. Although successfully adopting agile is not a trivial exercise, agile done correctly is highly rewarding for organizations and to the individuals involved. The most recent State of Agile Survey published by VersionOne in February 2014 shows that 88% of organizations are practicing agile. Over half of the respondents said they are using agile to manage the majority of their projects (52%). The report shows that Scrum is the dominant agile method used by a wide margin. The report also shows that the top 3 reasons for adopting agile are: Accelerating time to market Managing changing priorities Better alignment of IT to business objectives The report shows what the barriers to further adoption are and the percentage of organizations that ran into them: Inability to change organizational culture... General resistance to change... Trying to fit agile into a non-agile framework... Availability of personnel with the right skills... Management support... Project complexity... Customer collaboration... Confidence in ability to scale... Perceived time to transition... Budget constraints... A recent Forrester survey of more than 200 IT executives shows that IT application development leaders are looking to adopt and expand agile development practices to overcome limitations of their existing application development practices. Showing similar findings to the State of Agile Survey, the Forrester survey also found that agile is being used to speed time-to-market, yield better quality results, and improve IT alignment with business goals and customer satisfaction. Agile enables early detection of issues and mid-course corrections because it delivers artifacts much sooner and more often. The nature of agile is to include business leaders in day-to-day decisions and progress meetings. This collaboration yields tighter alignment and better overall satisfaction. The historical dividing lines between IT and the business are blurring as technology is being embodied in the business. 53% 42% 35% 33% 30% 28% 25% 23% 13% 13% Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 1
Agile is geared toward teams delivering valuable software; however, agile does not fare so well when it comes to addressing business process changes and transformation, organizational change management, or tasks that fall outside the scope of the project work. These include how to: Manage necessary changes to business processes and the business rules that govern them Effectively manage business SMES and other appropriate stakeholders, ensuring they are available throughout the project Gather and prioritize the most important features desired by the organization throughout the development cycle Consider what is required for wide user adoption Secure timely approval for decisions Address stakeholder discomfort with cultural, business, social or other non-technical changes related to software implementation However, these issues can be remedied, and the results from agile will only get better through placing more emphasis on business outcomes, using better discovery practices, and coordinating business change with agile development. In addition to the three benefits identified in the State of Agile Survey, the following benefits can be achieved: Better business outcomes Lower overall project costs Higher return on investment (ROI) Improved user satisfaction and adoption Here are some recommendations for ensuring you achieve the above benefits. 1. Focus on Business Outcomes Delivering a project on-time and on-budget is no longer adequate. In today s environment, the key question should be: Did the project deliver value to the business? Value is largely determined by how the system is embraced by the user community in the months and years after it is deployed. Delivering all functionality on time and on budget does not make a successful project if expected business outcomes are not achieved. An agile team delivering valuable software more quickly provides no business value if the software is never used. For example, delivering software on time, on budget, and even more quickly Does not guarantee that benefits outlined in the business case were achieved Does not guarantee user adoption Does not guarantee that expected ROI was achieved Does not guarantee a satisfied customer Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 2
Does not guarantee that the solution addresses the customer need Does not guarantee that sales were in line with forecasts Does not guarantee that there will be market demand for the product The success of a project should be measured using business outcomes, not by how much software was delivered. Examples for successful agile project business outcomes might be: Achieved a 55% ROI Increased production throughput by 26% Consolidated applications from 29 to 11 Achieved a total savings of $14 million in 9 months Increased the number of sales leads by 30% Increased labor efficiency by 32% 2. Utilize Dual-Track Agile The term Dual-Track Scrum, invented by Jeff Patton, an independent Agile Coach from AgileProductDesign.com, represents an approach to software development that assumes that there are two key tracks for agile product development: Discovery and Delivery, as shown in the diagram below: Discovery Track Quickly generating validated product backlog items in collaborative sessions with engineers & designers for Delivery Track. Delivery Track Developing releasable software based on backlog items qualified and defined in Discovery Track. This approach has a lot of merit and can eliminate a lot of frustration and costs in agile development. Often, agile teams have long and frustrating sprint planning meetings because backlog items are not well defined, understood, or validated. This results in slow velocity and extra development iterations because a basic understanding and design details are worked out during the sprint using code. The amount of waste and rework is very high because backlog items have not been defined and validated properly. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 3
To get around this, some agile coaches have recommended that teams spend 10% of their time grooming the backlog. Some agile coaches even recommend conducting separate meetings for grooming, sometimes referred to as Story Time sessions, for the sole purpose of grooming the backlog. An agile project, like other projects, is subject to scope creep in the form of user stories that get created but do not really yield substantial value, yet were thought to be good ideas at the time. Another problem is that teams and often product owners are not qualified to assess business value and validate ideas for need. A much better method to prevent these problems is to implement a dual track for discovery and delivery. I firmly believe this dual-track approach will increase velocity, provide higher quality products, and at much lower costs. In short, the discovery track is all about quickly generating validated product backlog items, and the delivery track is all about generating releasable software. Below is a list of some of the benefits that can be achieved from using this approach. Elimination of Features that Provide Little or No Value According to Standish Group Research, 64% of functionality is rarely or never used. This is the result of two things: 1) producing software without validating that there is a real need, and 2) not getting user adoption because not enough attention was placed on the user experience. The discovery track specifically focuses on these two things: validating the need and achieving a good user experience. Less Rework Agile is an iterative process. Iterative means that you do not finish a feature in one go. You code, get feedback, and continue this cycle until you have an acceptable product. Reducing the number of iterations reduces the time and costs. Providing the team with better information up front can significantly reduce the number of iterations. Cost Effective Validation The current practice of placing items in the backlog that have not been validated is a bad practice and happens all of the time. The goal should be to validate ideas in the fastest, cheapest way possible. Validating ideas using code and development iterations is slow, expensive, and wasteful. In dual-track agile, the discovery team can use Lean Startup concepts such as Minimum Viable Products (MVP), which are most often paper prototypes and surveys not code to validate ideas. The discovery team s job is to validate each idea and eliminate ones that do not add value. Better User Experience Designing the user experience is key to user adoption. However, incorporating user experience design into agile has been difficult, as it often disrupts the rhythm and pace of the agile team. Using dual-track agile helps solve this problem. User experience specialists work as an integrated part of the discovery team and focus on building and validating prototypes, which serve as a spec for the delivery team. Most importantly, the majority of user experience validation happens in discovery, rather than after the release of the software, resulting in lower costs and less rework. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 4
3. Develop an Outcomes-Based Project Vision All too often, teams get started on an agile project without having a clear idea of what the problem or the overall goal is for the project. This happens more frequently than any of us would like, even on projects with multi-million dollar budgets! Often, Scrum s emphasis on getting work done fast is misunderstood as a rush to develop with not enough thought to where the project should be going. Don t make that mistake every agile project needs a product vision. As Ken Schwaber, one of the founders of Scrum, puts it: The minimum plan necessary to start a Scrum project consists of a vision and a product backlog. The vision describes why the project is being undertaken and what the desired end state is. The product vision should present a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product the critical information we must know to develop and launch a winning product. If the project is for building a product, the vision should answer questions, such as Who is going to buy the product? Who is the target customer? Which customer needs will the product address? Which product attributes are critical to satisfy the needs selected, and therefore for the success of the product? How does the product compare against existing products, both from competitors and the same company? What are the product s unique selling points? What is the target timeframe and budget to develop and launch the product? If the project is to address a business process need, the vision should answer questions, such as What is the problem? What is the cause? What is the desired state? What is the context? Is a department problem or an enterprise problem? Does the problem directly impact external customers or is the problem internal? What is the target timeframe and budget to fix the problem? Answering questions such as these gives us the information to create a business case. It allows us to decide if and how the project should proceed. In addition to answering these questions, the vision should be persuasive enough to sell the idea. To achieve this requires two key things: the vision must be outcomes-based, and there must be promise of real life change. An outcomes-based vision: The vision should describe the expected outcome in crisp operational terms using business KPIs or metrics. For example, for a new A/P system, the metrics might be increased use of early pay discount, or reduced cycle time for invoice processing. For a campaign management system it might be reduced cost per contact. It is important to show before and after for whatever metrics are used. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 5
The promise of real change: For the numbers supporting your metrics to hold up to executive scrutiny, you need the second ingredient: the promise of real change. Spell out specifics where the changes will be applied. Focus on actual, tangible changes in the real world. There is a huge difference between investing money to enable something and investing money to actually do something. This means getting a crisp commitment from business users about what they will be doing differently in the real world as the result of the project. When your vision consists of these two ingredients, you have a highly compelling story. You start by presenting a target vision in terms that are highly meaningful to the executive suite. Then, you back it up with specific actions that will be taken to ensure that the targets are achieved. What could be stronger than a vision with known and defined business outcome targets accompanied by a set of easily tracked business metrics? 4. Use Impacts to Identify and Manage Business Change Agile teams generally only address changes needed for software. In starting a project, it is vital to identify all business changes that are needed to achieve the desired business outcomes specified in the vision. We do this first by gaining a good understanding of the problem and analyzing what must change to fix the problem. Often, there are more changes needed than just the software. In doing this, it is best to start by answering questions about what will be impacted by the project, such as the following: People Which people or organizations will be impacted by the project? Processes What business processes will be impacted? Governance What rules constrain the project? Data What data and knowledge is needed? Technology What IT services and technologies will be impacted? Projects What other projects will be impacted by the project? Once the impacts have been defined, we can use the information to manage project risk and the required business changes while the team builds the software. 5. Develop a Living Business Case A business case defines the business need and why we should make an investment. Beyond just being a rational thing to do, policy often dictates the need for a business case; the rules governing capitalization require that we explicitly define what we expect to achieve, at what cost, for what benefit, over what time. A well-written business case satisfies the preliminary (pre-capitalization) obligations that allow an investment committee to approve or reject a proposed investment. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 6
The business case should describe the problem or need and provide various alternatives of how the problem or need should be met. Alternatives might include doing nothing, developing a new solution, purchasing a solution, or modifying an existing solution. The business case should recommend the best approach for moving forward. All project costs and expected revenues are delineated in the business case as well as the ROI, generally shown as a net present value (NPV), internal rate of return, or as a payback. The business case should not just be used to obtain funding, it should be updated when major assumptions change and at the end of each release. If the changes are material, then the business case should be represented to the investment committee. A successful business case must be correct, unbiased, and clear: Cor rec t Include all meaningful costs (including non-it business personnel expense) and all meaningful benefits, such as increased revenue, new hire avoidance, or increased throughput. Unbiased All meaningful alternatives (such as build vs. buy options) should be analyzed and presented in a consistent fashion. If there are political concerns (and usually there are) or there is an obvious organizational discomfort with a certain development technology or an approach, these biases, strengths, and experiences should be presented. Clear The business case must be easily understood by all project stakeholders, including project sponsors, project managers, process owners, and subject matter experts. Many times, the financial analysis of alternatives appears complex to the nonfinancial stakeholder. It is important to keep things simple and present information in the business case with carefully defined terms, approaches, and results. When in doubt, write to the level of an eighth grader and use business terms while minimizing technical terms. Be sure to validate all numbers against the best available data sources, and any uncertainty and variances in estimated values should be reported. Non-financial benefits should also be captured and presented in a separate section. 6. Define Clear Objectives Achieving business outcomes requires more than just valuable software delivered by the team. It also requires user adoption and effective business change. Valuable software that is never used provides no value at all. Many people struggle defining objectives. One of the best methods for defining measurable objectives is the Return on Investment (ROI) Methodology developed by Dr. Jack J. Phillips and Dr. Patti P. Phillips. This methodology has proven to be a credible and practical approach for defining project objectives for various types of projects and fully addresses the accountability issues for the objectives. The methodology has been accepted and used in over 50 countries and is the leading approach to ROI accountability. The table on the next page shows the various types of objectives that are used in this methodology. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 7
AREA OBJ. TYPE FOCUS MEASURES Rapid User Adoption Reaction What is needed to simplify user activities? Usefulness Perceived Value Motivation Learning What do users need to become proficient with the solution? Skills Competencies Application How can we get users to adopt the solution? Extent of Use Frequency of Use Elimination of Workarounds Successful Business Change Impact What are the expected business outcomes? Increased Revenue Lower Costs Greater Throughput Less Defects ROI ROI What is the expected ROI? Monetary Return 7. Define and Manage Solution Scope Using Features It is features, not user stories that are delivered to customers and provide value to the customer. Generally, most requests from customers come as feature requests, not as a set of well-defined user stories that are ready for development. Sometimes, features are referred to as epics or themes in agile. A feature usually breaks down into several user stories. A feature can span several sprints; user stories should never span more than one sprint. When a user story has to span multiple sprints, this indicates that you re lacking granularity in your user stories. Features can be tested by the end-users; user stories are not necessarily fully testable by the end-user. In many cases, testing a user-story until fully integrated with the rest of the feature might only make sense to the developer. It is best not to mix features and user stories in the same backlog. When this happens, a significant amount of time is wasted by the team in having to constantly groom the backlog. The combination of user stories and features also makes it difficult for stakeholders to comprehend. In addition, there are many features that get identified that should never be built or even presented to the team until they have been validated to deliver sufficient value. This validation should be done in the most cost effective way, which does not include writing code. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 8
Standish Group Research shows that 20% of features are used regularly and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. Identifying and eliminating features that will never be used can result in significant savings and much faster time to market. Focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. As features are defined, they should be mapped to the business objectives they help achieve. They should also be mapped to the business impacts that were discussed above. Performing these two activities will ensure the software aligns with business strategy and will help integrate needed business change with software development activities. The diagram below shows this relationship. Business Need or Problem and Organizational Context Business Objectives { Adoption (Attitudes and Culture) Learning (Skills and Competencies) Application (Performance) Impact (Outcomes) ROI Feature Feature Feature Feature Feature Feature Feature Feature Feature Feature Included Features Descoped Features People Process Technology Data Rules Business Changes (Impact Analysis) Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 9
Summary Agility is a key capability of successful organizations. Agility is the ability to quickly adapt the organization and the business model to new customer demands, innovations, and a changing competitive landscape. We live in a time where virtually all business relies on IT. The consequence is that IT has to support business agility. Agile software development provides an effective process for responding to changes in a software development project. The main idea is to deliver software frequently to get feedback on what is being delivered and adapt accordingly. In agile software management, adequate responses to change are possible due to: 1. Frequent delivery of value to customers 2. Feedback on what is being delivered 3. Adaptation based on feedback and business change However, agile has been mostly limited to IT, more specifically to the software design, development and operations groups. The problem with this limitation is that even though those groups are agile, meaning they are able to respond adequately to changes, the rest of the company may not be as able as those groups. Another challenge that we are currently observing is the evolution from stand-alone to connected businesses. New collaborative business models involving tighter and more flexible integration of customers and business partners, Cloud Computing, Mobile Computing, and Social Computing are placing additional demands on IT and the business. The challenge in this evolution is finding the balance between the business demand for agility and connectivity on the one hand and the IT and Information Security requirements on the other. Information Security can no longer think in terms of perimeters, devices, and system security. There is no closed perimeter anymore. Devices are under constant change. Another aspect of the challenge is managing the users. Instead of focusing on the employees and a few business partners, there is a demand for rapid on-boarding and off-boarding of customers and business partners for these changing business and collaboration models. To meet that challenge head-on requires a stronger relationship between business innovation and software development, allowing organizations to explicitly link the value of software development with business development. Agile can be used to address the issue of business value by enabling organizations to: Break problems into smaller chunks to offer more opportunity for business impact. Splitting larger problems into smaller chunks and delivering minimum viable products puts results in the hands of the business sooner. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 10
Measure feature delivery based on business value. For example, features can be prioritized based on value and on cost. Application delivery focused around features provides the opportunity to measure delivery based on the scope, quality, cost, and business value of the functioning user stories. Take advantage of the disruption agile brings to extirpate old behaviors. Agile provides better techniques that allow organizations to get closer to the solution of measuring business value, but the real opportunity is that it offers organizations the chance to eradicate all old, non-business-value-focused behaviors as they move to take advantage of the change that agile adoption can bring. On many engagements the development effort accounts for 30% of the overall costs of a product. This means that everything else, from the product strategy and design through to deployment, accounts for the other 70%. In the race to focus on making that 30% of development marginally more effective, the industry is simultaneously ignoring the other 70%. For example, a Scrum team might be working well, but find benefit in a leaner process. This might add 10% improvement to the quality and/or throughput of the team. However, if the team isn t building the right product in the first place, or the biggest constraint they have is on deploying their products smoothly, this could be an awful lot of effort for a small return on investment. One of the most common failures is when agile is adopted as a delivery process only, with a focus on building more features faster. Without having the business involved and committed to helping deliver the right product, and without a way to measure what right is, a lot of the benefits that agile can deliver never make it beyond the development pit. Most management teams couldn t care less about the methodology used by their development team, be it agile, Lean, waterfall or your Aunt Marjory s homemade methodology. They just want to know when they ll get their hands on the product and how soon it can be monetized. Ultimately, they care about whether the outcomes of the process deliver results that the business can see. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 11
About the Author John Parker, Chief Executive Officer (CEO) of Enfocus Solutions, is a seasoned expert in IT strategy, requirements management, business analysis, project management, IT strategic planning, and IT value management. His experience and knowledge span decades, stemming from leadership roles as CIO and strategy consultant for Hospital Sisters Health System; executive vice president and chief technology officer for the national consulting firm MAXIMUS; founder, partner, and executive vice president of Spectrum Consulting Group; and partner at KPMG. Drawing from his vast knowledge of business analyses and project management, John leads the design and development of Enfocus Requirements Suite s valuable mind maps, templates, examples, and tools. John also regularly shares his expertise and insights at the blog on. John graduated cum laude from Baylor University. He is a Certified Public Accountant and a Certified Systems Professional. He also holds a Certificate of Mastery in Process Reengineering. About Enfocus Solutions Inc. Enfocus Solutions Inc. powers business value by capturing, managing, and leveraging the requirements of enterprise assets such as people, processes, and technology. Its flagship product, Enfocus Requirements Suite, a web-based tool, automates business analysis and requirements management best practices to enable successful product discovery and delivery. The tool is the only application available that permits and encourages stakeholders to directly contribute needs and collaborate with solutions teams. Enfocus Solutions Inc. is a privately held company headquartered in San Antonio, Texas. Please contact us to learn more about how your organization could benefit from the use of our technology and services to achieve higher project success rates. Contact Information Email: info@enfocussolutions.com Phone: (210) 399-4240 Toll-free: (877) 253-0275 Copyright 2014 Enfocus Solutions Inc. All Rights Reserved. 12