ETSF 01 http://cs.lth.se/etsf01 elizabeth@cs.lth.se Welcome to Lecture 3 Risk management & Agile PM Ch 2.6, Ch 7 except 7.3, 7.8 & 7.11, Ch 4.10-11, 4.13-15, P3 + slide info Risk Management Ch 2.6, Ch 7 except 7.3, 7.8 & 7.11 [Hughes] & Paper 2 [Boehm 1991] Paper 2: BW Boehm, Software Risk Management: Principles and Practices, IEEE Software, Jan 1991, pp- 32-41 What is risk? Boehm s Top 10 Risks [P2] An uncertain event or condition that, if it occurs, has a positive or negative effect on project s objective [PMBOK] A risk is potential problem; a problem is a risk that has materialized [Fairley 1994] Consists of both cause and effect Low top management priority (C) => staff moved from project (E) Use of new compiler (C) => integration problem & delayed training phase (E) [PMBOK] A Guide to Project Management Body of Knowledge (PMBOK Guide) [Fairley] R Fairley, Risk Management for Software Projects, IEEE Software, 11(3), 1994, pp. 57-67 Risk Personnel shortfalls Unrealistic time and cost estimates Developing the wrong software functions Developing the wrong user interface Gold plating Late changes to requirements Shortfalls in externally supplied components Shortfalls in externally performed tasks Real time performance problems Development technically too difficult Area SPM: Managing people SPM: Effort estimation Requirements Requirements Requirements, design Requirements, dev model QA / Verification, RE QA, SW Process Implementation, Verification Design, Implementation
In context 1. Identify project objectives 0.Select project 2. Identify project infrastructure Risk identification Risk assessment THEN Control & Monitor risk ÞTeam can then focus on progress rather than problems [P2:Boehm] 10. Lower level planning 9. Execute plan 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 6. Identify activity risks 7. Allocate resources 8. Review/ publicize plan For each activity Approaches to identifying risks include: Checklists usually based on the experience of past projects Brainstorming getting knowledgeable stakeholders together to pool concerns Causal mapping identifying possible chains of cause and effect Causal Mapping Risk assessment: Analysis & Prio Risk exposure (RE) = (potential damage) x (probability of occurrence) RE used to prioritize the worst risks Qualitative descriptors often used Al-Shehab, Abdullah J., Robert T. Hughes, and Graham Winstanley. "Using causal mapping methods to identify and analyse risk in information system projects as a post-evaluation process." Proceedings of ECITE 2004. Amsterdam (2004): 9-16.
Probability Impact Matrix Decision trees Extend or replace system? Risk planning: Five alternatives 1. Acceptance 2. Avoidance - find solution without risk 3. Reduction - reduce probability 4. Mitigation - reduce damage, e.g. taking backups 5. Transfer - e.g. outsource Risk Personnel shortfalls Unrealistic time and cost estimates Developing the wrong software functions Dev wrong user i/f Gold plating Late reqts changes Shortfalls in externally supplied components Shortfalls in externally performed tasks RT perf problems Technical difficulties Risk reduction techniques Boehm s Top 10 Risks [P2] Staffing with top talent; job matching; teambuilding; training and career development; early scheduling of key personnel Multiple estimation techniques; design to cost; incremental dev; recording & analysis of past projects; standardization of methods Improved software evaluation; formal specification methods; user surveys; prototyping; early user manuals Prototyping; task analysis; user involvement Reqts scrubbing, prototyping, design to cost Change control, incremental development Benchmarking, inspections, formal specifications, contractual agreements, quality controls Quality assurance procedures, competitive design etc Simulation, prototyping, tuning Technical analysis, cost-benefit analysis, prototyping, training
Risky commitments [Boehm] - Overscoping Main risk: Project target (scope) will not be met in time and on budget (cost/effort) scope lead time Traditional dev model sequential & doc-driven overpromise software capabilities in contractually binding requirements specification before they understand their risk implications Agile dev model iterative & code-driven neat ideas.. I ll code them up, and if they don t fit other peoples ideas, we ll just evolve things until they work. cost / effort Problems w effort estimates Estimators add a safety zone to cover difficulties Developers work to the estimate, so time is lost No advantage is taken of opportunities where tasks can finish early and provide a buffer for later activities Parkinson s law Work expands so as to fill the time available for its completion. => All buffers are usually consumed by end of project Effort estimates rel. Completion probability PERT* Program Evaluation and Review Technique A statistical tool for analysing completion time Three estimates for each activity (task) Most likely time (m) normal time Optimistic time (a) shortest realistic time Pessimistic (b) worst possible time Techniques to mitigate risk of inaccurate estimates - PERT Program Evaluation and Review Technique - Critical Chain expected time t e = (a + 4m + b) / 6 activity standard deviation S = (b-a)/6 *developed in 1950s
A chain of activities t e = (a + 4m +b) / 6 s = (b-a) / 6 A chain of activities t e = t e (A)+t e (B)+t e (C) s = sqrt( s(a) 2 + s(b) 2 + s(c) 2 ) Task A Task B Task C Task A Task B Task C Task a m b t e s A 10 12 16?? B 8 10 14?? C 20 24 38?? Task a m b t e s A 10 12 16 13 1 B 8 10 14 10 1 C 20 24 38 26 3 A + B +C?? A chain of activities t e = t e (A)+t e (B)+t e (C) s = sqrt( s(a) 2 + s(b) 2 + s(c) 2 ) Task A Task B Task C Task a m b t e s A 10 12 16 13 1 B 8 10 14 10 1 C 20 24 38 26 3 A + B +C 49 3 Critical Chain Method: Basic ideas For each activity: likely + buffer 50% / 90% = t e of PERT Move half of the buffers to the end
SW Porting: Risk management Securing the critical chain* with buffers Deadline *longest chain of activities consider task & resource dependencies SW Porting: Executing a Critical Chain Plan 50% / 90% estimates of each task. Duration = 50% estimates, The rest (51-90%) in buffers Project buffer = Sum(t_90-t_50) / 2 for the tasks in the critical chain Feeding buffer = Sum(t_90-t_50)/2 for chain connecting in to the critical chain Critical Chain: Fever Chart Delivery accuracy can be achieved WHEN project is Planned AND Monitored Risk Management CASE PROJECTS
SW Porting Project: Risk management Case Example: Estimating Risk Exposure Risk identification & analysis Brainstorming with core PM team - Software area teams contacted, if needed Other purposes - Bring project team together - Establish us - Discover product needs Risk list Risks Risk monitoring Select 5-10 top risks Monitor, e.g. - used as agenda at project meetings - identify actions to mitigate these risks Risk exposure = Severity * Probability = Risk priority Risk S P R Action External deliveries No 10 may be late and of bad quality. Lack of resources in area No 2 Graphics performance too poor 5 5 25 1) Plan a focus meeting and review the work break down and update the resource estimates. 2) Check if we can include penalties in contract 4 5 20 1) Make an analysis with Current, Minimum and recommended resources within the are. 2) Ensure that project needs are taken into account in line planning (through steering group) 5 3 15 1) Request to configure without Graphics accelerator. 2) Perform performance test and increase resource allocation. Case Example: Risk prioritization/exposure Severity Schedule Delay on Launch Functionality/ Performance 1 1-2 w Reduced performance on a non key functionality Perceived quality Customer notices reduced performance on a non key functionality 2 3-4 w Drop of a non key functionality Customer annoyed on quality of non-key parameter 3 1-2 m Reduced performance on a key functionality Customer annoyed on quality of key parameter 4 2-3 m Drop of a key functionality Customer complaint 5 >3 m Drop of several key functions Product return, nonrecommendation Probability 1 <20 % probability that risk will occur 2 20-40 % probability that risk will occur 3 40-50 % probability that risk will occur 4 50-60% probability that risk will occur 5 >60 % probability that risk will occur Scope: func + quality time General prio - SW Porting time - App Dev functionality - Maintenance - quality Application Dev Project: Risk Management Informal and integrated in Scrum process Depends on individuals Pre-study: - Product owner performs risk identification & prio - Affects backlog prio & communication with team
Application Dev Project: Risk Management During development / sprints: Risks managed continuously - Transparency incl continuous dialog with customer - Risks discussed in planning poker and included in estimates - If too much unknown, a spike can be performed - Hindrances mentioned at daily stand-up meetings Summary: Risk management Definition of risk, risk management Risk management Risk identification what are the risks to a project? Risk analysis which ones are really serious? Risk planning & mitigation what shall we do? Risk monitoring has the planning worked? Methods: causal mapping, probability impact matrix, decision trees Managing risk of delay with PERT and critical chain methods Useful exerises [Hughes]: 7.4-7.6 Boehm: Successful project managers are good at risk management. AGILE PROJECT MANAGEMENT Q&A CASE PROJECTS - Student groups - SPA - Fictive case projects - Ch 4.10-11, 4.13-15 [Hughes], P3 (not DSDM parts): Coram, Bohner, The Impact of Agile Methods on Software Project Management, Proc of 12 th Int. Conf. and Workshops on the Engineering of Computer-Based Systems, 2005. elizabeth.bjarnason@cs.lth.se
Principle-Driven Approach based on Agile Manifesto More valuable Individuals & interactions Working software Customer collaboration Responding to change Valuable Processes and tools Comprehensive documentation Contract negotiation Following a plan Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas, The Agile Manifesto, http://agilemanifesto.org/, 2001 Agile SPM Gradual detailing Work order Priority Just-in-time Agile project Self-governing teams Traditional project Level of detail at dev start Traditional Development Scrum Development Reqts Design Impl Testing Agile Development ReqtsDesignImpl Testing ReqtsDesignImpl Testing + a preparatory phase: High-level reqts + design! POST-GAME ReqtsDesignImpl Testing Same activities different sizing and sequence Agile principles and management are different PRE-GAME
Kanban: No iterations, team pull Max velocity WIP (work in process) / state Optimize average lead time / work item http://www.crisp.se/gratis-material-och-guider/kanban XP Development Stories Priorities (strict) Backlog Effort estimates Pair programming, TDD Analysis Feedback Auto test Continuous review Design Test planning Code base Testing Continuous integration Customer approval & release Kent Beck, extreme Programming explained, Addison Wesley, 2000 Agile (XP) Phases Exploration Planning: Release + per iteration Development (iterations) Pair programming A D T P T Productionizing Release Maintenance Maintce Rel Death Final Rel Scrum Roles Product owner customer view & scope Scrum master scrum processes Pigs Team - development Everyone else, e.g. stakeholders, mgmt - Chickens HL reqts Business prio Prototypng Effort estimates Prio backlog Estimate Capacity TCs Kent Beck, extreme Programming explained, Ch 21, Addison Wesley, 2000
Development in Scrum vs XP Iterations aka sprints Scrum XP 30 days prescribed, varies in reality 1-4 weeks Work in prio order Scrum XP team chooses stories in sprint planning team chooses stories strictly according to agreed prio (set by product owner) Managing change: Constant re-prio of backlog Scrum XP no changes in scope during sprint changes allowed within sprint for nonstarted stories Activity Planning Product Owner/Customer defines & prioritises User stories Backlog or Story card management Dependencies are built into the prioritised list, i.e. not explicitly marked Backlogs Story cards Effort Estimate Early estimates during exploration phase User stories estimated as part of iteration/sprint planning Time (man / person hours / days) or relative estimates (story points, bananas, gummy bears) Planning game (XP) or Planning poker (Scrum) Resource Allocation Capacity driven Project level: In exploration phase Iteration level: In iteration planning Within iteration: team pull, i.e. self-allocation
Risk Management Built into the process, e.g. stand-up meetings: Hindrances? Transparency, openess with information Iteration demos with customer / product owner Monitor Progress monitored by asking How much work remains? Frequent status checks -> Burn-down charts Traditional risk management techniques can be used, even if not prescribed & Control Management does not control in agile, rather facilitate Team is responsible for managing itself Team pull! Team responsible for its own work practice / process within the rules Regular feedback loops: pair programming, daily stand-up Sprint retrospectives Strengths of Incremental Delivery [Hughes 4.10] quickly delivers working increments user gets some benefits earlier reduces gold-plating focus on ROI avoids unnecessary overhead, e.g. keeping docs updated experienced engineers can be more productive shorten comm paths with customer & within crossfunctional teams feedback from early stages used in developing latter stages
Weaknesses of Incr Delivery [Hughes 4.10] weak long-term and overall perspective loss of economy of scale refactoring causes software breakages weak / missing documentation esp for large scale Dependent on personal knowl: negative for new members, transitioning to other team, audits, user doc Decision rationale, reqst-tc tracing may be lost Generalists have weaker specialist competence, e.g. reqts, testing, architecture Less structure/guidance for weaker engineers Even if agile PM is different, traditional methods and techniques are useful