Managing Risks Through Scrum: Inspect and Adapt

A few months back, I was presenting my project to an auditor as a Scrum Master. Most auditors like to get themselves convinced on the health of risk management processes in place in the project, and our case was no different. In most of my responses, I was particularly keen to emphasize how we have different processes in place and how it helps the team to continuously Inspect and Adapt, and in turn manage risks related to the project.

This thought seemed to work very well with the auditor and it got me thinking of the different ‘processes’ in place and how they addressed different risks:

Pair Programming

• Allows more than one person one the team to have knowledge of that particular part of the code base.

• Helps to avoid the situation where new team members work on a piece of code that they don’t know well and in turn make an error.

Story Kick Off

• Tracing back every story with an epic, in turn, assures there is a value associated with every story.

• Allows your to solve the business problems with the known variables available during kickoff.

• Allows you to focus on what and how to test once you have a story developed by laying out the acceptance criteria.

Daily Stand Ups

• Team collaboratively inspects the current status, identifies blockers, and comes up with actions to resolve them.

• Ensure team members do not get stuck on something which is not adding value; which, in turn, can risk putting the Sprint behind schedule.

Sprint Reviews

• Ensuring continuous feedback loops are in place with the product owner to review product increments.

• Ensuring sign-offs and confirmation on demos are received, thus ensuring all product increments are in line with business needs.

Automated Testing

• Ensuring functionality increments of the product do not break the previous working branch.

• There is an element of risk involved with manual testing in place with some scenarios getting missed during execution.

Retrospectives

• Ensuring the team is not making the same mistakes repeatedly.

• Learning from mistakes to be better prepared for future Sprints.

My biggest takeaway from the whole experience was the mindset change while looking at different processes we setup in our project. If we start identifying what risks we need to address in our project like Technical Debt, Scope Creep, Schedule Delays, etc. and then come up with a process to address it, it will lead to greater buy-in from all stakeholders.

Keep it in mind, even with this new way of looking at processes and associated risks, it is important to keep regularly evaluating every process in place, as risks that are addressed may no longer exist with regular changes happening in the product and business environment.