Risk management in an Agile way - presented at Agile Testing Days 2013
•
0 likes•926 views
Presentation on using Risk management in an Agile way. It describes how risks can be written down in a same kind of format as user stories and provides a practice on using risk management in a more dynamic, iterative and agile way.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Risk management in an Agile way - presented at Agile Testing Days 2013
Similar to Risk management in an Agile way - presented at Agile Testing Days 2013 (20)
Recently uploaded
Recently uploaded (20)
Risk management in an Agile way - presented at Agile Testing Days 2013
- 1. Risk management in an agile way
- 2. Introduction Edwin van Loon • ISEB Practitioner • Lean Six sigma green belt • Almost 15 years of experience within different testing roles • Living in Belgium • Working in the Netherlands edwinvanloon Edloon Edwin.van.loon@valid.nl
- 3. Interacts Is a life style tester Is a bug hunter Creates value Agile tester Re-focusses at lessons learned Motivates colleagues to use their talent Is efficient and effective Is efficient and effective Aims for preventing defects Eliminates wasteoverhead Improves his/her weakness Improves continuously Creates value Is lean Is lean Is eager Enjoys Reconsiders Coaches Uses all kind of tools Researches Explores Is result driven Anticipates Anticipates Uses his/her talent Guides Is creative
- 4. Agenda What is a risk? Risk management process and it’s agility Risk management within Agile Optional: Integral risk management
- 5. Caused by a situation [Risk] Related to user a situation involving exposure to danger: activities (requirements) flouting the law was too much of a risk [mass noun]: all outdoor activities carry an element of risk [in singular] the possibility that something unpleasant or unwelcome will happen: reduce the risk of heart disease (un)certainly
- 6. Related to user activities (requirements) [Risk] A factor that could result in future negative consequences; usually expressed as impact and likelihood. [Product Risk] A risk directly related to the test object. (un)certainly
- 7. Definition of product risk A possible THREAT related to one or more REQUIREMENTS (user stories) and related to an OCCURANCE that could cause DAMAGE to an organization or person A requirement without any risk is a non needed requirement A risk without a requirement is a missing requirement Is a philosopher
- 8. User stories and product risks User story As a <person>, I would like <a need>, So that <the added value of this need to the person> Risk As a <person>, I fear that <a failure occurs>, due to <an occurrence>, causing <impact>
- 9. Example Related User story User story As an employee of the managed services organization, administror, I would like to be able to centrallymy financial transactions any time and manage manage the financial master data so any place at that changes in master data only need to be submitted once. Primary business risk Secondary business risk As an employee of the managed services organization, administrator, I fear that inconsistencies occur in the financial transactions, I am not able to submit the master data, due to the fact that master data is not not distributed correctly to the local administrations, the master data is available or outdated, causing a lot of manual work to thefinancial damage (100.000 euro per day) dissatisfied customers and manage services organization on correcting the inconsistencies
- 10. Risk management process 1. Risk Identification 2. Risk Assessment 3. Risk Mitigation 4. Risk Management
- 11. Are you using a risk management process? 1. No, because it has no added value to me. 2. Yes, for initially identifying and assessing risks. 3. Yes, for initially identifying, assessing and reporting on mitigated risks. 4. Yes ... and it is even iterative based (reconsider risks during the project).
- 12. Risk identification How: • Expert interviews • Independent assessments • Risk templates / Mindmaps • Fishbone diagram • Project retrospectives • Risk workshops • Brainstorming • Checklists • Past experience Be able to think impending doom
- 13. Risk assessment Likelihood 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. x Complexity of technology and teams Personnel and training issues Conflict within the team Contractual problems with suppliers Geographically distributed team Legacy versus new approaches Tools and technology Weak managerial or technical leadership Time, resource, budget and management pressure Lack of earlier quality assurance activities High change rates High earlier defect rates Interfacing and integration issues Business impact: 1. 2. Frequency of use of the affected feature Criticality of the feature to accomplishing a business goal 3. Damage to reputation 4. Loss of business 5. Potential financial, ecological or social losses or liability 6. Civil or criminal legal sanctions 7. Loss of license 8. Lack of reasonable workarounds 9. Visibility of failure leading to negative publicity 10. Safety
- 14. Predict likelihood of victory
- 15. Risk mitigation Likelihood H L 3 1 Test techniques/ Test coverage, Test levels, Entry and exit criteria Test techniques/ Test coverage, Test levels, Entry and exit criteria Test techniques/ Test coverage, Test levels, Entry and exit criteria Test techniques/ Test coverage, Test levels, Entry and exit criteria 2 4 1 2 Business impact H
- 16. Risk mitigation Average coverage Average coverage Minimum coverage L Minimum coverage Business impact H
- 18. Get inspired by ordinary situations
- 19. Risk management Defect management Average coverage Average coverage Minimum coverage L Minimum coverage Business impact H
- 20. Involved parties at agile (SRUM) Product owner Multidisciplinaire Agile team SCRUM Master ? Test manager
- 21. Agile proces Daily Product owner Product Backlog Sprint 2-4 weeks Planning meeting Sprint Backlog Demo / Retrospective
- 22. Embedding risk management Re-define/prioritize Daily Test manager Quality owner Measure Defect management Risk Backlog Sprint 2-4 weeks Planning meeting Sprint Backlog Demo / Retrospective Product Backlog Product owner
- 23. Product and Risk log # Area BI 1Accoun High ting 2Data Low migrati on 3Accoun Low ting 4Accoun High ting User story Count Id As a … Risk I would like … 10U1 Accountant to centrally manage my accounting master data 4U2 Accountant to migrate the different company transactions to one single administration 5U3 Administor to be able to manage my financial transactions any time and at any place So that …. Id I fear that … due to …. 6U4 Accountant to be able to check data consistency can be whether master data ganranteed changes are applied correctly centrally and decentrally management inconsistencies in master data wrong data in the financial reports delay in booking transactions R4 Changes in master data the fact that the master inconsistenties in are not applied data is not distributed master data correctly to the local administrations Risk traceability Defect causing …. all departments will use R1 The master data can not authorizations are not the same data be managed set up correctly the financial data can be R2 The profit and loss incomplete and wrongly consolidated easily account is not consistent migrated financial data anymore transactions can be R3 I am not able to submit the fact that master booked as quick as the financial data is not available or possible transactions outdated User story General Acceptance criteria, Status, Etc. U1 U2 U3 U4 U5 R1 P S S R2 Risk R3 R4 R5 P P P S Shippable product S P
- 24. Software Quality Costs Integral risk management Corrective costs Preventive and Appraisal costs ECL Conformance level Balances quality measures Total costs on software quality
- 25. Reactive maturity level Software Quality Costs Reactive Situation: • (Nearly) no testing or defect prevention • (Re)act on production failures ECL • Total cost of quality can be reduced by 50-100% Possible improvements: • ‘Sell’ test and quality awareness • Train business and project in testing Corrective costs Preventive and Appraisal costs Total costs on software quality
- 26. Passive maturity level Software Quality Costs Passive Situation: • Testing present, but not structured/effective • Large gaps between cause and detect of a failure ECL • Total cost of quality can be reduced by 20-50% Possible improvements: • Introduction of structured testing • Train business and project in detecting issues • Introduction of quality management Corrective costs Preventive and Appraisal costs Total costs on software quality
- 27. (Over) active maturity level Software Quality Costs (Over)Active Situation: • Focus on ‘detecting and preventing all issues’ • Lots of overhead and no quality cost awareness ECL • Total cost of quality can be reduced by 20-100% Corrective costs Preventive and Appraisal costs Total costs on software quality Possible improvements: • Introduction of integral quality management • Increase test efficiency or good enough testing • Introduction of AGILE and continuous improvement
- 28. Juran curve Software Quality Costs Balanced Situation: • Quality is managed on a integral level • Efficiency of quality measures is continiously ECL management and improved Balances quality measures Possible improvements: • Stay AGILE • Continue improving Corrective costs Preventive and Appraisal costs Total costs on software quality
- 29. What is the quality of your organization/project? Passive Balanced Software Quality Costs Reactive (Over)Active Corrective costs Preventive and Appraisal costs ECL Total costs on software quality
- 30. summarized • Risk identification helps to identify missing and non-needed requirements at an early stage • Initially priorities risks on business impact only • At risk mitigation, define the minimum coverage for quality assurance and the average coverage for the required flexibility • Re-consider the priorities during the project based on issue density per area • Focus on balancing quality measures (instead of on testing measures only)
- 31. Stay Ahead Be lean Please evaluate my presentation and use for this the AgileTD Mobile App which you can find at www.touchmyconference.com/ATD2013. I would appreciate your feedbacks. Thank you very much!
Editor's Notes
- Op een laag pitje – At low ebb
- Economic conformance levelExponential growth
- Reactive QA maturity (far left block)On this level mostly corrective measures are present. Failures are found in the production-environment after going life. Next to the direct costs of correcting the failures the costs of marketing to correct the damage/decreased image are also high. The total cost of quality is much too high and can be reduced by 30-50 percent. The organisation/project only reacts on failures that occur.2. Passive QA maturity (corrective and detective measures at a late stage) The focus within the level lies on finding the failures on the right side of the V-model during dynamic testing (often during the acceptance test). Testing is present but often only in a unstructured and ineffective way. Almost no preventive measures are present.3. (Over)active QA maturity (far right block)Lots of preventive and detective measures are taken. Lots of test types are present and less defects are found after going life..... But testing and QA are too expensive. Finding a defect will take more time than correcting them. The damage occurred by the remaining defects is almost null.So: Too much detective and preventive measures in relation to the corrective measures. The total costs of quality can be reduced by reducing the number of preventive and detective measures (or by defining more efficient measures).4. Balanced QA maturity The level in which the right balance between the quality measures is reached and proven via the collected metrics.
- Reactive QA maturity (far left block)On this level mostly corrective measures are present. Failures are found in the production-environment after going life. Next to the direct costs of correcting the failures the costs of marketing to correct the damage/decreased image are also high. The total cost of quality is much too high and can be reduced by 30-50 percent. The organisation/project only reacts on failures that occur.2. Passive QA maturity (corrective and detective measures at a late stage) The focus within the level lies on finding the failures on the right side of the V-model during dynamic testing (often during the acceptance test). Testing is present but often only in a unstructured and ineffective way. Almost no preventive measures are present.3. (Over)active QA maturity (far right block)Lots of preventive and detective measures are taken. Lots of test types are present and less defects are found after going life..... But testing and QA are too expensive. Finding a defect will take more time than correcting them. The damage occurred by the remaining defects is almost null.So: Too much detective and preventive measures in relation to the corrective measures. The total costs of quality can be reduced by reducing the number of preventive and detective measures (or by defining more efficient measures).4. Balanced QA maturity The level in which the right balance between the quality measures is reached and proven via the collected metrics.
- Exponential growth
- Exponential growth