A few months back, as a ScrumMaster, I was representing my project to an auditor. Most auditors like to be convinced of the health of risk management processes that are in place for the project, and our case was no different. In most of my responses, I was particularly keen to emphasize how we have different processes and how they help the team to continuously inspect and adapt and manage risks related to the project.
This explanation seemed to satisfy the auditor, and it got me thinking about the different Scrum processes and how they addressed our associated risks:
- Story kickoff
- Traces every story back to an epic, ensuring that there is a value associated with every story.
- Solves the business problem with the known variables available during kickoff.
- Focuses on what and how to test, once we have a story developed, by laying out acceptance criteria.
- Pair programming
- Avoids restricting the team to only one person who is knowledgeable about the code base, or a even certain section of it.
- Avoids situations in which new team members work on a piece of code that they don’t know well, resulting in errors.
- Daily stand-ups
- The team collaboratively inspects the current status, identifying blockers and coming up with actions to resolve them.
- Ensures that team members do not get stuck on something that is not adding value, which can put the schedule at risk.
- Sprint reviews
- Ensures that continuous feedback loops are in place with the product owner so that the team and stakeholders can review product increments.
- Ensures that sign-offs and confirmation on demos are received, verifying that all product increments are in line with business needs.
- Automated testing
- Ensures that functionality increments to the product do not break the previous working branch.
- With some scenarios getting missed during test execution, there is an element of risk involved with manual testing.
- Ensures that the team is not making the same mistakes repeatedly.
- We learn from mistakes to better prepare for future sprints.
My biggest takeaway from the whole auditing experience was the mindset change after looking at different processes we set up in our project. Identifying which risks you need to address, such as technical debt, scope creep, and schedule delays, and then devising a process to address them, leads to logic around the process and buy-in from all stakeholders.
Of course, even with this new way of looking at processes and associated risks, it is important to regularly evaluate every process, because some addressed risks may cease to exist as the result of regular changes in the product and business environment, while others could crop up.