Agile/Scrum-Risk Control

When you are using the agile/scrum framework one of the principles of these frameworks is creating “just enough paperwork” easier said than done. There are some things that you will still have to document so they don’t fall by the wayside, I believe that one of them is your risk plan and the way you will control the process of risk evaluation. You will still have to document HOW the team will handle control of the risks after you have identified them and WHO will control the outcome. You will need to document and assign multiple risk response options, not if the risk happens but WHEN they happen to the development of the application, control of the risk can involve some of the processes located below. Here are 2 of the risk templates I have used for previous jobs, the Risk Tracker, and Risk Plan template. 1. Schedule Risk Sessions. Even though you are meeting in a stand-up every day and uncovering impediments from team members, new risks will start to appear as the agile/scrum project progresses. Risks that your team has identified early in the planning of the project (earlier post) will morph and change as the agile/scrum project progresses. 2. Re-evaluate your Risk Responses. Why re-evaluate? In your prior meetings that were held on the subject of risk, the team has assigned the first response to alleviate the risk, which might have changed as the agile/scrum project picks up steam and product backlogs items come and go. 3. Document Workarounds. Quick-fix actions you might have to perform and the workarounds needed to alleviate the issues, are usually reactionary and should not be a permanent solution to the issue. Business/stakeholders hate workarounds and good attention to technical excellence should alleviate any needs for the workaround. 4. Contingency Plans. Execute the response option that you assigned to a specific risk. 5. Update Plans. You MUST update and improve your risk plan; also face to face communication is key to the well-being of the entire agile/scrum team and business/stakeholders. Agile teams are usually a creative group of individuals, try to be creative in your risk identification/response meetings, think of all the possibilities where risk will affect your agile/scrum project. Revisit your Work Breakdown Structure (WBS) document (earlier post) and try to think of where risks may impact your project, technology, communications, resources, third party, business considerations. Agile/Scrum products by design move at top speed, if you are willing to devote time, attention, and teamwork to the details it will result in the control that you need to deliver a successful agile/scrum project.

Agile/Scrum-Risk Control