Are retrospectives and daily stand ups replacement of risk management

Question

Currently we are following a lot of the Scrum routines like stand ups, refinements, planning 1/2, demo, retro...

The past few months we were heading downwards showing poor performance and delivering bad product/code at the end of the sprint. At first glance it seems as if we are too optimistic when we are planning and committing. After that, during the sprint we hit a lot of problems, and due to the lack of time which partially is caused by the poor commitment we end up with what I've stated at the start of the post - badly implemented features with a lot of bugs. Our PM suggested to try and include some sort of risk management during our refinements/planning which sounds reasonable since it's obvious that there are things that we do not take into consideration during the refinement and when we actually hit a problem it's usually during the sprint when we are already committed.

After some investigation about risk management in Scrum I end up with the idea that maybe Scrum has it's own risk management implemented in it's very nature. The daily stand ups with the questions "What have I done yesterday", "What problems did I hit", "What I'm gonna do today" sounds to me like a pretty good risk investigation and the retro meeting at the end of sprint being a lot longer than an usual stand up meeting is giving a chanse to analyze in more depth things that the team thinks are important.

Since Scrum methodology itself has a lot or rituals that are taking from the time of the team, along with some additions specific for our team like having intentions written for each story, having technical design document (very high level one but still..) we already have somewhat heavy process and I'm wondering is there really some truth in what I think, that retros and stand ups could be a good replacement of standard risk management and could these or other Scrum rituals/routines be used in order to better our risk management rather than including entirely new methodology in our work?

Answer 1

It sounds like Scrum practices have been adopted using a cargo cult approach. If you are consistently delivering poor quality results then you are missing some practices.

I would consider "What problems did I hit" to be a significant question. Addition detail is needed. Was it solved? If so, how was it solved? If not, what needs to happen to get it solved? What impact will it have on the sprint?

From a risk management perspective, examine your processes with a view to answering the question: "If we eliminated the process what is the risk that code quality would decrease?". Before adopting a new process, consider how likely it is to increase code quality? There are well-researched data on the effectiveness of a number of techniques.

When planning consider the risk that the estimate is wrong. For things that are very similar to other you have done successfully, the risk should be low. If your team does not have a clear understanding of how to implement the solution, then risk would normally be high. Do the same with how certain your understanding of the story is/will be.

Take some time to understand the techniques you are using. One of the best decisions I ever made was to spend a couple of months researching development processes before launching a major project. That project was delivered ahead of schedule with higher quality than normal. Consider my comments on Who pays for learning curve?

Answer 2

I think you are missing one of the key aspects of Scrum.

This is how it works:

Firstly the team decides on it's definition of done. This is all the things you expect to do when you deliver good quality finished features.

Next you get to work. At the end of a time-boxed sprint you measure how much work you got to your definition of done (do not include work that is still in progress). This amount then becomes your guide for what you can achieve in future sprints. You may find in some future sprints you do a bit more or a bit less. A lot of teams will calculate their capacity (called velocity) using a rolling average of what they got done in the last 3-4 sprints.

In this way the team finds out what it's true capacity to do work is. There is no such thing as 'being optimistic in your planning'. There is only what you have measured to be your team's capacity.

If you find that your team regularly does not get all the planned work in a sprint completed then the answer is very simple. Put less into future sprints.