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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s