Advanced Release Planning

Transcription

1 Agile Project Management Jim Highsmith Chapter 8 Advanced Release Planning

2 Failure to keep Release Plans current! Management needs to know how a business problem will be solved, its cost, how long it will take, and how much risk is involved! Agile teams response: How do we commit to something with a reasonable assurance of delivery and at the same time leave room for change, learning and surprises? Key is in understanding the purpose of the release plan to: Foster a better understanding of project viability and feasibility Outline assessment and mitigation of risk Enhance a team s ability to prioritize capabilities and stories Give the team a feel for the entire project Enable answers to management questions about value, schedule, and cost Create a comfort level about the project with both ream members and management Create a plan for partial deployment

3 Wish-based planning (balancing capacity and demand) Managers think they can push teams hard enough they will respond heroically typical view Reality the result is dysfunctional teams, not high performance teams. managers wishing the team can deliver 50 features in the next release because of market demand, even though developers know that 30 features is more realistic. Wish-based planning results Plans created where demands exceed capacity and development groups are forced to accept the demands Schedules and features are missed Management typical response improve estimating and planning skills until the desired plan emerges

4 Developers often lack Appropriate estimating skills putting themselves in poor positions by always saying no Good negotiating skills Management and marketing folks are adept at negotiating Developers are at a disadvantage with a lack of these skills The ability to respond to managements use of plans as motivators. Internal motivation always trumps external / forced motivation

5 Multi-level Planning Executive and managers need some degree of predictability for financial and marketing planning as well as the ability to adapt to new situations and information. as well as needing to monitor project status Best perspective to think at the capability level and not the story level Team s plan reflects reasonable commitment to deliver the planned capabilities but retains flexibility at the story level regarding which stories would implement the capability

6 Product Planning Structure (Figure 8-2) Roadmap (2 years) Iteration plan the day-to-day work plan for the development team. Wave plan spans several iterations and planned at the story level may represent a partial deployment release Release plan results in a deployable product (capability or feature level) Release (12 months) Wave (3 months) Iteration (2 weeks) Product roadmap shows a multi-release map for a product s evolution over several years

7 Product Planning Structure (Table 8-1) Characteristic Release Wave Iteration Timeframe Long-rage Medium-range Short-range (6+ months) (3 months) (1-4 weeks) Level of Detail Capability Story Story/task Commitment Type Project feasibility Capability commitment Deployment Final release to customer Possible interim relapse to customer Large financial products software company Product management group had 2-3 year roadmap of business areas and capabilities to be implemented. worked out an 18 month feasible release plan of 300 capabilities for several teams each team developed a 3-month story-level wave plan and then developed detailed story and task level iteration plans. Each of the plans was updated periodically. Story commitment Customer review process

8 Capabilities Capability describes a high-level business or product function that is complete and valuable a story delivers a piece of useful and valuable functionality to a customer. Story may be 2-10 days of work Capability may be somewhere between days Capability cases bridge the gap between the wants and needs of the business and what the system is to do for the business users. Team's can commit to delivering a set of capabilities, while leaving the detailed requirements and specifics about implementation (the stories) to the project team. Companies need predictability and flexibility. Using a capability-story approach can provide both predictability at the capability level and flexibility in exactly how those capabilities are delivered at the story level.

9 Creating a Product Backlog & Roadmap Backlog grows over time as capabilities are converted to stories Information about each backlog item improves Detail is not added until it is really needed to avoid normal changes (Just-In-Time philosophy) System Change Requests (SCRs) are also added (typical for legacy applications) maintenance requests, persistent defects, small enhancements, technical debt reduction

10 Product Lifecycle (Figure 8-3) Product Conceptualization Cycle Initial Product Development Cycle Continuing Product Development Cycle Product Deliver Product Roadmap Product Backlog Product Release Plan(s) Wave and Iteration Plans Continuous Flow of Value Product conceptualization phase leads to a project chartering session to through the product vision, project scope and boundaries and release planning activities. generating release, first-wave, and first-iteration plans. new stories are identified and the backlog list is updated Note: UML modeling can be valuable as a documenting technique, but is also has caused many organizations to go diagram crazy.

11 Optimal Planning Structures oriented to mature agile organizations. Two scenarios: 1. A product development effort in which the product is continuously evolving over a multi-year period most typical 2. A major product development or re-development effort in which the minimum releasable functionality takes 12 or more months to deliver a significant amount of functionality must be developed before an initial release can be made

12 Value Point Analysis Stories are small chunks of functionality and estimates are either in terms of relative size (story points) or absolute terms (hours). Value points translate this data to cost? Beneficial value points: indicate to executive management a serious, quantitative approach to value assist teams in making priority decisions during release, wave, and iteration planning can assist teams in negotiating depth of story functionality (e.g. is a 3-value-point story worth 21 story points?) help increase ROI by pushing the planning of high-value capabilities and stories earlier

13 Value Point Determination Done by the product team, headed by the Product Manager. The development team needs to estimate effort at some level (story, capability) to develop a full release plan Value Point estimating can be just-in-time (JIT) Story Point estimates have a built-in feedback process to correct bad estimates not the case for value point estimates Two methods to produce relevant & useful value point estimates: 1. Limit estimates to a short series of numbers (1, 2, 3, 5, 8, 13) 2. Allocate total value points on a percentage basis to capabilities (caps the number of value points in a set of stories) Capability point values (1, 2, 3, 5) 5 capabilities with capability points 2, 3, 3, 5, 1 Convert to percentages 2/14, 3/14, 3/14, 5/14, 1/14 14%, 21%, 21%, 36%, 8% Assign value points to the stories in each capability and sum these for each capability Total value points for each capability should have a 14%, 21%, 21%, 36%, 8% distribution

14 Story Cards with Value Points (Figure 8-4) As a sales associate, the ability to calculate the total amount of the sale V-13 C-13 As a sales supervisor, the ability to verify the adequacy of the customer's credit rating. V-2 C-21 As a sales executive, the ability to view all sales b product type, geographic region, and sales associate. V-3 C-8 During iteration planning if stories with low value-points but high story-points, an assessment of whether or not the low-value story (V-2) is worth the estimated work (C-21) should occur.

15 # Stories, Dollars Value and Cost Delivered (Figure 8-5) Cum Value (NPV) Cum Cost # Stories NPV Actual Costs Iterations

16 Non-customer facing stories technical debt reduction stories, refactoring stories. Technical stories that support customer facing ones. These are typically investment type stories. Priority setting issue who decides? Product teams do not usually understand technical debt reduction, maintenance items and technical infrastructure stories. Collaboration and trust is needed a prerequisite characteristic of a mature agile development process

17 Planning themes and priorities To bring an appropriate focus to business value, project need both an overall vision and shorter-term themes that implement the vision. Themes can be useful for iterations and in larger projects for waves Types: Business function groupings of capabilities, features or stories Business process flow is a sequence of business functions that produces some final result (e.g. order-to-shipment, bill-topayment ) Risk mitigation focus early on where technical hurdles need to be overcome Partial deployment plans may impact feature/story implementation priorities and create wave themes

18 The key question a team should ask itself at the end of each iteration is, What is keeping us from shipping a product right now? Note when practicing one iteration-at-a-time planning, higher level themes may get lost. Teams should not get in a positon where pieces of multiple capabilities are finished but nothing is usable to the customer.

19 Increasing productivity Do better, or do less! Familiar data: over 64% of software functionality is rarely or never used, whereas just 20% was often or always used. One of he reasons for projects becoming larger and larger is the absence of immediate feedback on efforts to accomplish individual features the source of featuritis User requirements list of 50 to 200 items. The most interesting thing learned was by the time we got to 20, nobody is interested in the remaining 80 or more items. Agile project can improve productivity by doing less in two dimensions breadth (the list of requirements) and depth (implementing a req t or story but altering the depth of functionality.

20 Risk Analysis and Mitigation Core risks that dominate software projects: 1. Inherent schedule flows 2. Requirement inflation (creep) 3. Employment turnover 4. Specification breakdown 5. Poor productivity The best bang-per-buck risk mitigation strategy we know is incremental delivery. Tom DeMarco and Tim Lister

21 APM techniques that address schedule risk Team involvement in planning and estimating Early feedback on delivery velocity Constant pressure to balance the number and depth of features with capacity constraints Close interactions between engineering & customer teams Early error detection/correction to keep a clear working product Requirements evolution is a rational process in which the development and customer teams are constantly evolving the requirements of the product while considering other constraints. Requirements evolution is a joint effort where all parties participate in deciding on features. Requirements creep occurs when there isn t a joint effort, when customers or developers add features indiscriminately.

22 Risk: Specification breakdown When customers and the product team fail to agree on specifications. The product manager, aided by the executive sponsor, is charged with either stopping specification breakdown or halting the project until the specification process can be fixed. The product manager and team are responsible for creating a viable specification decision making process.

23 Planning and Scanning (looking forward) Frequent re-planning based on progress to date and new information gathered during development iterations is essential to deal with the uncertainty risk. Agile teams can place too much emphasis on adaptation or evolution and too little on anticipation (in planning, architecture, design, requirements definition). Failure to take advantage of knowable information leads to sloppy planning, reactive thinking, excessive rework, and delay. Remember: Agility is the art of balancing. Too great an emphasis on adaptation (we can always fix or refactor later) means that you do not take advantage of information that should be known. Example: Spending a week at the beginning of a project defining customer req ts and constructing a skeleton data model may improve the quality of the plan and speed of development.

24 Scanning looking ahead to learn the unknown as quickly as possible. Reduce uncertainty by a systematic, proactive, and early gathering of information or identifying the information that needs to be gathered at a future point. Managing risks estimating the probability something will happen and the negative impact that would result. Managing assumptions continually scanning to determine if the assumptions still are valid Maintaining a key future decisions list assuring that the appropriate information needed is available at the future point in time.

25 Timeboxed Sizing For capabilities during release planning Constraining size rather than estimating size was much faster than trying to discuss and agree on the scope. Early sizing in release planning is inexact regardless of method used so For timeboxed sizing to work all parties need to understand the benefits and the limitations of the approach.

26 Other story types The overriding concept should be that all work should be accounted for in release and iteration planning. Maintenance and enhancements requests (SCRs) converted to stories. Task Cards circumstances where several days of work cannot be included in a story card. Change Cards the feedback from customers and product managers at the end of each iteration may result in change requests. Inter-team Commitment Story Cards large projects where one team commits to do work for another team. Decision milestones critical point in the project where decisions are required. see Figure 8-6 Performance cards key operations and performance req ts (nonfunctional req s) see Figure 8-7

27 Work-in-Process versus Throughput Figures 8-8 and 8-9 Multitasking DAYS Project1 Project2 Project3 Analysis Assumes zero time for task switching Design Project1 Project2 Project3 Programming Non-multitasking strategy DAYS "More throughput and less work-in-progress" Note: Multitasking (moving from one project to another) adds task switching overhead.

28 Emerging Practices Kanban is a new technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied. A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end. Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we'll assume a simple phased process of: (1) analyze the requirements, (2) develop the code, and (3) test it works. Handout

29 Consolidated Development Background Management approach to staffing and dealing with conflicting priorities among new development, customization, and maintenance work IT organizations tend to divide into new development and maintenance Independent software vendors (ISV) put new development, maintenance & enhancement into a single group with customization for particular clients handled by a separate group. New developments teams seem to get bogged down in maintenance work and key customers want their customizations work done quickly. Sutherland Single organization works on all facets of delivery (new functionality, enhancements, SCRs) Governed by a strategic prioritization system Allocating work to three simultaneous, overlapping iterations

30 Consolidated Development (continued) Sutherland Weekly iterations target maintenance or minor enhancements Monthly iterations target specific enhancements Quarterly iterations target major new functionality Prioritization is a strategic organizational process involving the product manager, the CEO and other key executives. Approach requires: Agile delivery is a proven approach & management supports the process Continuous integration and automated testing is ingrained in the process Effective functioning and integrated product management, development, and QA

31 ???? Hyper-development and Release FINAL THOUGHTS Release planning gives the team a game plan that compensates for the often short iteration focus of agile projects and gives product marketing a context in which to make key priority decisions about capabilities and stories. Release planning gives management and executives a baseline against which to determine the feasibility of delivering a high-quality, releasable product within the identified constraints.