Accept the risk


There is much said and written about risk management. Elaborate plans are written, checks and milestones are put in place; all there to lower the risk. Any risk for that matter. I've seen reports taking fire hazard or flooding into account. That is really taking things seriously. The guy or girl is probably praised for it by his or her manager for being thorough.

Coffee machine

They continued their discussion and concluded, reassuring each other: that it's just what it is, nothing much more they could have done about it. This happens often, right?

I found that I was really inclined to agree with the colleagues. I know that they are still working in a part of the (large) organization that doesn't have agile working or DevOps implemented yet. Why not, is not something I want to go in right now. The thing I was thinking about, they knew upfront what risk they took. It failed but it was a calculated risk, right? Delaying the release would probably have cost the company even more money.

"Act on things you can change..."

How does that translate into my Scrum team?

 We don't write risk analysis reports up front. So does that mean that if we release a feature, we basically have no clue what risk we are taking? No, of course not. We do know for sure is that the release is small, so we have a pretty good picture of what the risks are.

Do we skip risk analysis in Scrum? No, we 'do' risk analysis. How? By simply discussing the technical implementation of the feature at tech-spike sessions. By putting our heads together and come up with a solid architecture that the team agrees on, we diminish risks. The agile architecture is made by the team. Sometimes helped by other system specialists if needed. The whole team thinks about and challenges each other, about possible solutions.

In this way the more complex features are covered by this discussion. The more simple (but also security vulnerable) features are (automatically) tested by the more OPS knowlegdeable part of the team. These guys, in my case know about tooling and how to implement it in their team.

On an operational level this is as far as I think we should go. On strategic or tactical level of the (or a) company I think these elaborate reports about risk analysis, make sense. 

I basically learned this: Act on things you can change and react to things that you cannot change.

Apart from flooding or burning down the place, I think we're OK.