Risk management in Scrum – Insights

I am writing this post after exchanging tweets with @flowchainsensi.

The Nokia test provides criteria to measure the adequacy of Scrum implementation. If we have ScrumBut (aka inadequate Scrum), then we should not expect the accomplishments in terms of higher velocity, better quality and increased customer value.

Even while we are implementing ScrumBut, we should strive to show some value from using Scrum. This value will allow us to remove handicaps for Scrum implementation and therefore improve our score in Nokia test.

ScrumBut introduces risks to the project. Such risks should be managed using the rigor of Risk Management (RskM) process. PMBOK® and CMMI® have in-depth addressing of RskM details. Traditionally, software development is driven by risks. There are two drivers that can help us start brainstorming for risk identification.

  1. Risks originated from ScrumBut.
  2. Risks originated from not achieving the value which management expects as a result of using Scrum.
I suggest implementing weekly RskM as 30 minutes meeting to:
  1. Monitor the risks
  2. Update risks status
  3. Identify new risks
  4. Create actions to address risks

Such meetings and the outcomes tasks are planned in the sprint backlog.

Insights on delivering value

The word value is being used so often with stretched interpretations. From the insights shared in this post, I think the word value is so virtual and not always easy to define up-front. It is something that you admire when you see it and you cannot have prescription for. Of course we always target customer satisfaction and to meet the project constraints. However,  we know that this objective can be done in different ways that produce different value. This value is related to and judged by the customer and development organization while it’s delivered by the project team.

How we improve the value to be delivered while in the mean time we can not define it? Continue reading