Our team has 1 BA, 3 devs and 1 QA. We are trying to follow
SCRUM as much as possible and since recently the term
Risk management was not a part of our dictionary.
However the past few months our team had to work on a part of our product which is very old, most of the people who have implemented it are no longer part of the company and the domain itself is pretty fragile and at the same time, complex, so we end up with continuously delivering bad code in every meaning of the word. The testing also get worse since the tester (we had 2, now it's only 1) was/is not yet familiar with this part of the application and together with the huge amount of bad code and the lack of experience the end result was poor performance sprint after sprint. Sometimes finishing the stories but introducing bugs in the system, other times, not able to finish what we have committed to and sometimes a mix of both.
As a result, there was a proposal from our manager to try and adopt risk management as part of our working process. As it is right now, the idea is that there is nobody personally responsible for the risk management related stuff. We decided that for now this should be obligation of each member of our team.
What we have done was to make some sort of brainstroming and try and come up with as many risks as we can identify and then try to investigate each individual risk and find solution to each one.
Even though the above approach seems good enough for some of the members of our team (for now) I personally don't find it very constructive. Past weeks or two I've read a lot of articles about this topic. I know I can't become a risk manager for 2 weeks and it will take a lot more than several articles to gain the knowledge necessary but I what I see is that there are people who have came to the same conclusions as me and now I would like to go even deeper on the topics that I find most burning for my particular case.
So straight to the point. During the brainstorming we were able to identify a lot of "risks" but analyzing the results I came to the conclusion that they are not the root cause of the problem but just indicators that something is really going on bad. We have identified a lot of risks like "Deploying code with bugs on live", "skipping tests", "Performing tests which don't cover the full functionality", "Deploying partially implemented functionality" and so on, but for those are not the real risks, those are just the idicators/symptoms of something more general. And I don't know if in terms of risk management it's good idea to generalize things so much, but for me there is on basic risk which is - "Delivering of bad product" and a lot of so called
event trees to get to realization of that risk, where most of the events are triggered by the same thing - a lack of knowledge in the team about this part of the product, and maybe just not enough experience in the software development at all.
The reason to write this question is because I don't know to what extent the risk management should deal with these problems and what is just, how to say... just a team issue. From my prespective, it's useless to focus on a risk like "Deploying a code with bugs on live" if it's obvious that still the team is struggling with getting familiar with the whole complexity of the project and all hidden interactions.
What happens is that every time I try to squeeze more time for certain task because I know from experience that certain types of tasks are historically difficult and potentially hide a lot of complications once you start to work on them, I get the response that I'm basing my request on fears and that quite the opposite - if there is something that we already have done (even though it's not 1 to 1 the same) and already we had to deal with some of the problem then now we should need less time, and it should be easier for the team this time. I must admit, this sounds quite logical and it's hard to find arguments against that except the reality that despite all logic, more than often even though it seems that we are hitting the same wall, it's actually
almost the same wall and this
almost usually leads to the fact that we have to invest the same amount of time as the previous time and even worse it seems like we haven't learn our lessons and repeat old mistakes.
Well, it's hard for me to decide how much it's due to the fact that the team is not able to learn fast enough, and how much of the problem is due to the fact that we leave the same thing to hit us twice the same way.
I've read that the best way to identify risks is the experience, and problems that you or the team had in the past. This sentence makes me think that this case is not completely out of scope of the risk management theory. However, I must admit that having not the same, but similar issue more than once and not being able to deal with them in fasted and cleaner way is also a problem of experience, abilities of the team itself. But in 2 weeks sprint it's hard to hit a problem, learn from it, and on the third week to be able to quickly solve similar issue. It's a matter of learning and learning takes time.
One thing that I find almost useless is to waste time trying to solve symptoms when, at least for me, the root cause is clear but it just requires more time to overcome it, like the issue with learning and getting better. For me it's a risk to take a story where you know from previous experience that there might be hidden complications but I can not find a lot of arguments why this is risk and not just say... incompetence.
What I would really like to make clear for myself is - what part of the above may be considered as risk. What should be dealt with the tools of risk management (and how) and what do you think about the things that stay outside the scope of risk management. I know that this team is capable, I know this team lack experience and I think that it will be a huge waste of time and effort if we decide and go for solving issues which looks much more like symptoms than a root cause and how do you think such issue should be handled?