Dual-Track Agile for Product Managers 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. January 2014
For those of us on agile teams, we are often faced with long and frustrating sprint planning meetings because our backlogs are filled with items that aren t well defined, understood, or even validated. The result is slow velocity and extra development iterations because our basic understanding of the feature as well as design details are worked out during the sprint using code instead of beforehand. The amount of waste and rework is high because backlog items have not been properly defined or validated. To get around this, many agile coaches recommend that agile 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. Like other projects, an agile project is subject to scope creep in the form of user stories that do not really yield substantial value but were thought to be good ideas at the time. Another problem is that agile teams and often product owners are not qualified to either assess business value or to validate ideas for need. A better method to prevent these problems is to implement a dual-track agile approach for discovery and delivery. I firmly believe this dual-track approach will increase velocity, provide higher quality products, and result in much lower costs. Dual-track scrum, or dual-track agile, is an approach to software development invented by Jeff Patton at AgileProductDesign.com that assumes there are two key tracks for agile product development: discovery and delivery, which are depicted 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 tremendous merit, and when properly understood and applied can eliminate a great deal of frustration and cost during agile development. The discovery track is all about quickly generating validated product backlog items, and the delivery track is focused on generating releasable software. Below is a list of some of the benefits that can be achieved using this approach. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 2
Elimination of Features that Provide Little or no Value According to Standish Group Research, at least 50% of features are hardly or ever used. This is the result of two factors: 1) producing software without validating that there is a real need, and 2) not obtaining user adoption because insufficient attention was placed on the user experience. The discovery track specifically focuses on these two factors: validating the need and achieving a good user experience. Less Rework Agile is an iterative process. The word iterative means that you do not complete 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 cost of development. 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 that happens all of the time. The goal should be to validate ideas in the fastest, least expensive manner 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 often consist of paper prototypes and surveys and 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 a key factor in obtaining 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. UX specialists work as integrated members of the discovery team and focus on building and validating prototypes, which serve as a spec for the delivery team. Most importantly, most user experience validation happens in discovery instead of validating after software release, resulting in lower costs and less rework. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 3
Discovery Team Discovery teams are formed in a similar manger to the formation of traditional agile development teams. However, the skills on an agile discovery team are quite different than the skills required for an agile development team. One skill that is potentially common to both teams is business analysis; however many organizations tend to place business analysts only on the discovery team. Good discovery teams blend entrepreneurial skills and research gathered from the market to make intelligent product decisions. They actively build a collaborative culture focused on asking the right questions and validating ideas. Using Lean Startup methods, good discovery teams start with hypotheses and assumptions not requirements. Solution requirements (user stories) are not defined until ideas have been fully validated and the related hypothesis and assumptions have been confirmed. A discovery team is a small, multi-disciplined team. The ideal team is eager to engage early with customers and users, is problem-focused, and has an experimentation attitude. A good discovery team has the following skills: ppuser Experience/User Centered Design ppbusiness Analysis pppricing and Financial Analysis ppcustomer Discovery ppimpact/gap Analysis Discovery teams should collaborate internally and directly with customers and users to discover and validate the problem, as well as with development teams for building the product. Development is done in an iterative fashion using research gathered by the discovery team. The goal is to reduce the number of development iterations and associated rework and to eliminate low value features that do not meet validated business needs. The final product of the discovery team is a continual flow of user stories that populate the product backlog. Each user story is mapped to discovery team artifacts such as stakeholder and business needs, personas, scenarios, and prototypes. User stories are written in a consistent format and follow the INVEST model: ppindependent ppnegotiable ppvaluable ppestimable ppsized Right or Small pptestable Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 4
Discovery teams focus on problems first, product second. Great product teams gain a deep understanding of what the customer problem is before defining the product and its features. The goal of discovery is to understand the customer s core problem and to validate the potential solution before building the solution. Discovery teams have user-centered design specialists that validate ideas early with customers using prototypes. They try to get customer buy-in and validate their understanding of the problem. They keep iterating and revising the prototype and associated marketing pitch until they can consistently earn positive signals that customers are willing to buy. Ideally, discovery teams are working one or more months ahead of development teams to validate new product initiatives including major features and partner integrations. Discovery teams validate critical product ideas and features using Lean Startup methods. Discovery teams create a hypothesis and methodically test the minimum feature set, price, and acquisition model. Heavy emphasis is placed on validating how well the product solves customer pain. Discovery teams perform the following functions, which are explained in more detail in the subsequent sections: ppvision and Scope Establish and maintain the product vision, ppdiscovery Discover business and stakeholder needs, ppdesign Support the development team in the design of the solution, and ppvalidation Validate ideas and assumptions. Vision and Scope Vision Before starting a project, it is important to develop a shared vision. Developing a shared vision is often done using collaborative workshops. Attendees at the vision planning workshops often include the product owner, business stakeholders, technical SMEs, designers, customer representatives, and the project manager. The goal for the initial workshops is to elicit a shared understanding among the project team about the business landscape. This sets the context for the project and ensures that everyone understands what the problem or opportunity is and why it s important. There are many advantages to bringing together everyone who has a stake in the success of a project, but one of the primary reasons is to reach a shared vision for the project as quickly as possible. Achieving an understanding and commitment, not only from the immediate project team, but also from the wider organization will pay big dividends in the success of the project. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 5
Once a comprehensive understanding of the project landscape has been gained, it is important to create a narrative vision of success that will guide product development. To create a successful product, it is necessary to take into consideration business, stakeholder and technical requirements, and constraints. The product needs to deliver business value, be technically feasible, and likely to be adopted by end users in support of their daily activities. Creating a desirable product does not happen by accident. The project, and ultimately the design, is directed by both business and customer goals, to ensure that the project team remains focused on delivering value. Designing in this way ensures that arbitrary features or functions are not added to the project and that the project is delivered within the planned constraints of time, scope, and budget. Scope The real challenge: project teams and executives rarely have a good process for evaluating and prioritizing the right things to build. Project teams need a process to evaluate problems and opportunities, reduce risk, and prioritize activities so that focus is placed on the features that deliver the most value. Standish Group research evidences this problem in their 2013 CHAOS Manifesto report. Standish Group Research shows that 20% of features developed and implemented are used regularly and that 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. Focusing on the 20% of the features that yield 80% of the value will maximize the value generated from investment in software development while improving overall user satisfaction. Reducing scope and not delivering 100% of the functionality is not only a valid strategy, but also a prudent one. Many project teams confuse or do not know the difference between project and solution scope. Project scope includes the work needed to create a product or deliver a service or result. Project scope defines the work required to create and deploy the product. The project scope statement is prepared by the project manager. A business analyst prepares the product or solution scope. The solution scope describes the characteristics, features, or functions of the product or service to be built. Solution scope is all about the solution to be implemented: how it will look, how it will function, and other characteristics, etc. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 6
In other words, solution scope is the set of capabilities a solution must deliver to meet the business need. Written correctly, the solution scope will help create a shared vision. Solution scope will: Support the business objectives, Have clear and concise statements that collectively describe the components of the solution (i.e., features), Prioritize features such that low value items and items that do not address the business need are eliminated, Describe the impacts of people, processes, technology and data, and Focus on the solution, not on the work to be done. In defining scope, it is best to do it as a set of features and to describe how that set of features impacts and integrates into the business context (people, processes, and technology). The diagram below shows solution scope defined in this way. Solution Scope Context Functionality Impacts What people, technology, processes, data, and rules are impacted Features What needs to be done Discovery For a product to be useful, it needs to have acceptable levels of both utility (i.e., whether it provides needed features) and usability (i.e., how easy and pleasant these features are to use). To design better, more useful products, it is important to stop designing solutions too early and start instead with product discovery: a process that helps the team better understand the problem properly so they don t just design things better, but design better things. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 7
Discovery involves understanding the problem and business need and why the team is undertaking the project. Here, the team should discuss and answer questions such as: What is the problem? Who has the problem? Which user needs are we trying to address? For existing products, what are the shortcomings we need to fix? How will solving this problem help our business? How will success be measured? There are several methods that can be used to help get the answers to these questions. Fishbone Diagrams and The Five Whys are two root-cause analysis techniques frequently used to define a problem in terms of user needs and business goals. As we said before, the real challenge is that product teams and executives rarely have a process for evaluating the right things to build in the first place. Product teams need a process to evaluate market opportunities, reduce new product risk, and put the right things on the product roadmap. Let s explore the concept of discovery and its various components. The objectives of discovery are: Business Model Test critical Business Model assumptions. Customer Gain a complete understanding of the customer need or problem. Product Discovery Determine the options available to solve the problem and which is option is best given the competitive market. User Adoption Gain an understanding of the users and what is required for adoption. Discovery can be decomposed into four key tracks. Each one of these tracks requires different skills and the discovery team should possess the skills to address each of these areas. Business Model Discovery The goal of business model discovery is to test assumptions related to the business model. Many product managers work hard on the technical proof of concept, but often skip proving the business model (revenue flow). In other words, once they are convinced that the product works, they assume their price, sales channel, and marketing will bring in the customers. These days, the technical side is the easy part. Proving the business model requires a different approach than proving the technical concept. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 8
Generally this is done by preparing a business model canvas and validating assumptions. The business model canvas was originally created by Alexander Osterwalder and addresses the following nine interrelated parts: Key Partners Key Activities Key Resources Value Propositions Customer Relationships Channels Customer Segments Cost Structure Revenue Streams A business model is a dynamic system, not a collection of independent parts, so a change to one element is likely to have an impact on one or more of the other parts. Customer Discovery The purpose of customer discovery is to gain a complete understanding of the customer and their needs. All too often, product teams start development work on features without even knowing anything about the customer or the need it solves. Typical questions that need to be answered as part of the customer discovery process include, among others: Who are customers for your product? Are there sufficient customers to support a sustainable business model (market)? What are the customers top problems? Are others trying to solve the problem and if so, why you? Will the product solve their problems? How much will customers pay? Product Discovery At least 50% of software features developed and implemented are rarely or ever used. This represents a large cost as development organizations not only have to pay the cost of development but also must pay for the cost of maintaining the software features moving forward. The goal of product discovery is to identify and validate the features that will deliver the most business value. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 9
User Discovery Even though the team may have a validated customer need, if it cannot get users to adopt the solution to support their daily activities, then the product will not be successful. Building a positive user experience is critical for any product. User-centered design (UCD) skills should be a key part of every discovery team. User-centered design is about discovery and research. It starts with gaining an understanding of the users and their activities. Good UCD also involves early and continuous developer involvement. Best practice is for UX experts to work with users to design and validate ideas in discovery and be able to provide support in the form of conversations to developers on agile teams. The benefits of constant designer involvement include: 1) a higher quality, more usable product, 2) access to a design coach, and 3) less rework and refactoring due to poor interface implementation. Validation Product managers know the importance of validating an idea before committing to building it. However, validation is easier said than done. In fact, it s possibly one of the hardest things to do in the product life cycle, otherwise products and startups wouldn t have an abysmal 90%+ failure rate. Validation is a primary function for the discovery team. Their job is to validate ideas and assumptions prior to commencing development work. In other words, ideas must be validated before placing user stories in the backlog. Below are some of the benefits derived from better validation: When it comes to new products, by definition you re making assumptions sometimes a lot of them. You need to validate the key hypotheses and assumptions as early as possible. Some of the assumptions are going to be wrong. If the ones that are wrong are significant, there can be significant risk to the business. Validation helps avoid the most common problem of spending time and money building something nobody wants. If you come across a failed product, chances are that it was based on an idea that the founder believed was cool and interesting, rather than something that solved a real problem for real people. If you decide that you re headed down the wrong path, it s easier and a lot cheaper to change course sooner rather than later. Validation helps refine ideas and learn more about users. Validation helps determine if people will buy the product before it is built. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 10
Design Agile practitioners recommend getting straight to the business of coding and delivering working software as soon as possible. However, working software is not a means to an end. If the software doesn t add value to both the business and the end customers, then it s just worthless code. Design is a critical part of both discovery and delivery. Design cannot be left to chance and should not just emerge as a by-product of software development. To deliver a compelling, valuable, and desirable experience that hooks customers, converts them, and keeps them coming back, it is necessary to design the experience in a different way. To create a desirable product with an engaging user experience, it is best to take bits from the most influential design disciplines design thinking, service design, product design, graphic design, user-experience design and apply them in an agile project environment. Design should be explicit, yet should be fully integrated into the project and product lifecycles. Design should be viewed as a continuous process that starts in discovery and continues in delivery. The key for design is to do just enough to get started and make informed decisions about the direction of the project during delivery. The project landscape will definitely change, so it is important to avoid creating waste or stockpiling anything that could become obsolete with change. Just enough design should be completed just in time for development. It is important that the project, and ultimately the design, is directed by both business and customer goals and remains focused on delivering value. The discovery team must use facilitation techniques to drive out the key customer journeys and the design direction, while soliciting input about technical feasibility and business viability from the delivery team. A fundamental shift that has occurred with agile is to move away from the practice of doing too much of anything including design before realizing any value. The idea is to do just enough to get started and then to refine as the team learns more. User Stories After features have been discovered, defined, and validated, it is time to start populating the backlog with user stories. Good user stories are much more than just statements. A good user story consists of three elements, often referred to as the three Cs: 1. Story (Card) 2. Conversations (discussions between team and business SMEs) 3. Confirmations (acceptance criteria) An initial set of user stories is defined as part of the discovery process. Additional user stories are added by the team as needed during the development process. It is best to define acceptance criteria just in time before user stories are placed in a sprint. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 11
Collaboration Communication and collaboration are key to successful agile implementations. Agile places emphasis on verbal communication and interaction rather than documentation. Therefore it s essential that everyone on the team understand the relevant communication objectives and protocols. It s important to be clear about how each function and individual is expected to interact, and to deliver and communicate outputs to the team and the wider business. It is highly recommended for agile teams and the product owner to be collocated. This same principle applies to discovery teams but sometimes this is not possible. However, this is sometimes not practical for discovery team as they need to get out of the building to gather real insights from users and customers. Collaboration on discovery teams can sometimes be more difficult as team members must provide support to the development team as well as deal with external customers and key business stakeholders from sales and marketing. They are many collaboration mechanisms that apply to agile development that also applies to agile delivery. Below is a short description of some of these concepts: Feedback is a way of communicating with individuals on the team to help them improve competency or social interaction. The structure is based on Pendleton s rules what was done well, what was not done so well, and what could be improved. The main objective is to provide the opportunity for growth in a positive and constructive manner. Stand-ups are daily team meetings that are generally conducted every business day. They are short, succinct daily meetings that keep the team informed of progress being made, current and intended activities, and any roadblocks. Demonstrations provide the opportunity to demonstrate and get feedback on the design at the end of an iteration or sprint. Showcases are often attended by stakeholders from beyond the core project team. Retrospectives are generally conducted at the end of each sprint. They provide a measured forum for looking at aspects of the project that went well, those that didn t go so well, and those that might be improved. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 12
Regardless of the methods used, it is important that discovery teams address the following to promote effective collaboration: Cross-functional team conversations with discovery teams often represent different viewpoints. When business analysts and designers need to have conversations with the business, it makes sense to have these conversations once and have crossfunctional input. Regular end-customer feedback is about engaging with end customers to learn what s not working in the design so that designs can be adjusted before they are developed. Ideally, feedback should happen as frequently as possible, but no less often than once per design iteration. Regular feedback from business stakeholders who may or may not be directly involved in the project team. This gives everyone who has a stake in the design the opportunity to give input and feedback about the designs. These meetings will likely need to happen once or twice within a design iteration. Frequent interaction with developers to ensure that the design ideas are feasible and also to get input about what the technology can do to enhance the designs. These need not be formal meetings but the conversations need to happen frequently, probably multiple times a day. Interaction with QAs on the project to make sure that the tests reflect important interaction, visual design, and usability criteria too. 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. Copyright 2014 Enfocus Solutions Inc. All Rights Reserved 13
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 14