Vanilla Agile Risk Management with Traditional Techniques
The Sprint Planning meeting is just too long and never finishes on time. I finished my tasks on time, the story couldn’t be completed as there was a dependency on him. I just didn’t have time to follow it up. Not my fault. Yet again, there are left over items in the sprint. We couldn’t finish all the committed stories as some of them were too complex for their correct effort complexity estimation. Ohh Gosh, once again the priority of the tasks have changed in the middle of the sprint, there are new urgent items that have to be done. My sprint commitments have gone for a toss. We moved to Agile from waterfall and it has been few sprints into it, though even here vision is unclear, requirements are evolving and our sprint commitments are failing. Velocity is just been a number, Burn down graphs conclude nothing concrete and useful. How do we cater support/maintenance work with Scrum? Does any of the above statement sound familiar to you, if yes probably it is the time to evolve and adopt KanScrumBan wrapped around XP practices. KanScrumBan is the combination of Kanban and Scrum and uses the best features of both. While Scrum framework helps the software development teams to self-organize, collaborate, improve efficiency constantly, work in small iterations, and avoid management overhead, applying lean methods like Kanban , flavored with XP practices can extend these benefits.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (15)
Similar a Vanilla Agile Risk Management with Traditional Techniques
Similar a Vanilla Agile Risk Management with Traditional Techniques (20)
Más de oGuild .
Más de oGuild . (20)
Último
Último (20)
Vanilla Agile Risk Management with Traditional Techniques
- 2. Vanilla Agile Risk Management flavored with traditional practices Employee-Personal Presented By: Ankit Tandon ©AnkitTandon
- 3. Agenda • Understanding Risk • Traditional Risk Management Approach • How does Agile Handles Risk? • My experimentation with it Employee-Personal©AnkitTandon
- 4. Understanding Risk • Outsourced Performance Testing of the application to the third party and it seems like it wont be completed in time. • Reference platform may not be available for Middleware/Application development. • Big upfront design to get its specifications right. • Lack of support of key stake holders • Lack of knowledge to make a crucial architectural decision. Employee-Personal©AnkitTandon
- 5. Many Words for Same Employee-Personal RANDOMNESS UNCERTAINITYVARIABILITY RISK ©AnkitTandon
- 6. Risk Defined • Risk is uncertainty that matters, i.e, uncertainty that if realized impacts one or more objectives in either a negative (threat) or a positive (opportunity)* Employee-Personal *As quoted by Dr Alan Moran
- 7. Traditional Risk Management • In traditional risk management process, a complete list of potential risks with their priority and a plan to mitigate them is prepared upfront. • It is based on the assumption that at the start all the uncertain events can be identified • A lot of time and effort is spent towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion. Employee-Personal
- 8. Risk Management In Agile • The process is rather emergent in nature • The realization of risk occurs quickly and abruptly • Delay time is less as the risk gets highlighted in the daily stand up, review, retrospectives or release/sprint planning meetings • It is more a real time thing in Agile • An application of Agile principles make the process robust and antifragile Employee-Personal©AnkitTandon
- 9. …..But Is it enough….?? Are an application of these Agile practices enough to manage risks in an Agile bound project? Or with little adjustments can the traditional risk management be more powerful with Agile methods? Employee-Personal©AnkitTandon
- 10. How Did I Do It? • Embraced bare minimum traditional risk management techniques • Customized it with core Agile principles to make it a lightweight framework • Applied Agile principles to avoid self creation of intrinsic risks or uncertain events • Applied engineering / technical practices for treatment (As required) • Used Product Backlog to manage risks Employee-Personal©AnkitTandon
- 11. Identification Analyze Treatment Monitoring Employee-Personal The Flow.. ©AnkitTandon
- 17. Risk Analysis • Risk Analysis is done by deriving following: -Probability (Likelihood of happening it) -Impact (Cost, Schedule, Technical Performance, Reputation etc) -Exposure is the quantified potential for loss that might occur as a result of some uncertainty (Multiplication of Probability and Cost) Probability and Impact are measured on a scale of 1-5 with an explicit definition of what a 1,2,3 ,4 and 5 means. Employee-Personal©AnkitTandon
- 19. Risk Register Description Probabi lity Impact Exposure Response Sprint New features may require significant rework and skills 4 3 12 Technical Spike - TA2031 created for investigation Sprint 11 Database Scalability 4 3 12 Pending Potential security flaws discovered 4 4 16 Security task created. TA2045 Sprint 11 Third party Integration challenges 3 2 6 Neha to sync up with Akamai team to figure out discrepancies and challenges. US 1103 Sprint 12 Video streaming schedule slipping - Technical challenges 2 3 6 Manav and Chris to pair program. TA 2099 Sprint 13 Employee-Personal ©AnkitTandon
- 20. Identification Employee-Personal The Flow.. Analyze Treatment Monitor ©AnkitTandon
- 21. Risk Modified Kanban Board Story Tasks In Progress Review Done US1101 US1144 US1271 Task Task Task TaskTask Task Task Task Task Task Task Task Normal Task Negative Risk Task Positive Risk Task Employee-Personal
- 22. Risk Burn Down Chart Employee-Personal 0 5 10 15 20 25 30 35 Day1 Day2 Day3 Day4 Day5 Exposure EXPOSURE ©AnkitTandon
- 23. Risk Management Activities In Various Agile Meetings Employee-Personal Meetings Risk Identification Risk Analysis Create Response Monitor Response Residual Risk Approval Release Planning S S S Backlog Refinement S S S Sprint Planning S S S Daily Stand Up C C C S Sprint Review C C C S S S=Should be C=Could be ©AnkitTandon