1

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?

1

3 Answers 3

3

One of the benefits of using the Scrum framework is that it reduces risk.

How does it do it? Well risk is all about surprises. Often that means thinking you will get X amount of work done, but finding that you have only got Y amount of work done.

With Scrum, rather than guess at what we will get done we measure actual progress. That is not just progress in completing development tasks, but true progress in terms of completing functionality to a stated standard (a definition of done).

Let's take the example from your question. The team is working in an area of the code they are not familiar with and that is not well built. This is clearly going to have an impact on the rate of progress of the team.

The Scrum approach would be to first agree the definition of done. Perhaps the team will look to refactor each component that they work with to get it to a minimimum quality standard? Perhaps they will document any un-documented code? Perhaps they will do more code reviews as the code is so problematic?

Once the team has agreed the definition of done they start work. In the first time-boxed sprint they see how much they can get to done. That does not include work still in progress or technical tasks that on their own deliver no business value. No, the true progress is how much functionality is potentially shippable.

At the end of the first sprint the team sits down and works out how much they completed. They then use that as a guide for future sprints. After a few sprints the team has a realistic idea of their capacity. This allows them to make a stab at how long it will take to do work in the future. Now this may well come as a bit of a shock. Often using this approach reveals that the team's capacity is nowhere near as large as was imagined. But at least the team is being realistic now and hence has much reduced the risk of surprises.

Scrum doesn't stop there. Not only does it encourage the team to be realistic in measuring it's capacity, but also it encouragest he team to think of ways to improve ('inspect and adapt'). It is possible by continually reviewing how things are going that the team can find ways to improve their effectiveness and hence improve their capacity to do work.

4
  • 1
    I find a lot of tips in your answer. It sounds as if you are here, observing the process personally. Yes, we need more code reviews, it would be really great to be able to refactor some of the most problematic parts and the biggest problem imo the fact that the team is not ready to face the reality (more precisely how much of quality product we can deliver each sprint). What happens is that we deliver enough to satisfy the higher-ups but the poor quality is biting us almost immediately in the form of incidents.
    – Leron
    Aug 14, 2016 at 10:25
  • From your experience do you know a way to point that to the team and the managers without forcing a defensive reactions or making the others feel uncomfortable with this. I truly believe that once we accept that our current level is Y it will be much easier to progress to X and above, but I can't find a way to bring it to the team in a way that it will be accepted as something positive and not like accusation for example
    – Leron
    Aug 14, 2016 at 10:28
  • This is a very common problem. The trick is to make visible the true progress of the team. If the higher-ups want you to cut corners then highlight the impact this has (e.g. "because we skipped code reviews last sprint we lost 2 days this sprint fixing issues"). Hopefully they will then see that doing things properly is the best approach. Aug 14, 2016 at 10:30
  • Doing the right things is doing the things right. Yes you are 100% right. Really appreciate your answer.
    – Leron
    Aug 14, 2016 at 10:32
2

Most of what you are looking as risk, appears to be process deficiencies. (A deficient process is a risk and should be mitigated.) Identifying the risk and cost of the various outcomes of the deficient process may help you focus your process improvement efforts. It appears the main risk is introducing bugs into production, and it has a high probability.

Actions like "skipping tests", "Performing tests which don't cover the full functionality", "Deploying partially implemented functionality" and so on are factors that may or may not lead to "Deploying code with bugs on live". Review which of these contribute to or could mitigate any introduced bugs.

Given the code is old, complex and fragile, there are several process issues that I would expect.

The code likely doesn't have automated unit tests. These may go a long way to mitigating the risks. Before modifying code, the developers should create a reasonable set of unit tests to ensure that their changes don't break existing functionality. The changes should also have unit tests, so that the change can be verified.

Having the developers peer review each others code is another technique that often uncovers issues. You may want to try other techniques like pair programming.

I have often worked on many systems where incomplete functionality was released. There are various mechanisms for controlling whether the code is active. New functionality that depends on a new code value can often be kept inactive by not introducing that code value into production. Other code may need a switch mechanism, for which I prefer a disable flag. Flags can add additional complexity, so you may want to remove them when the code is complete.

0

"the risk management theory" - There is no single risk management theory. We're not quite as bad as some other disciplines where there seem to be more theories than analysts, but it is not a single homogenous theory.

That said, I've got a couple of observations that I hope might be helpful

  1. Overall observation - most of the value in risk management is the discussions; if you're analyzing and discussing the risk, you should be improving your team's understanding of and ability to manage the risk. Someone once quipped, "the point of planning is the planning, not the plan"; the same holds true for risk management.

  2. You seem to be proceeding down the path towards more mature risk management, but I'd urge one change:

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.

I'd urge you to insert a step between brainstorming and finding solutions. I would suggest either (a) grouping the risks into like categories (which has the side effect of improving collective understanding and calibrating the team) and/or (b) prioritizing the risks. This can be a "soft" prioritization with qualitative analysis, or a "hard" prioritization with calibration & quantification. Many teams do both; a first pass at qualititative prioritization and then a more detailed pass at quantitative prioritization. (there are ample online resources to discuss these).

The point is to reserve 90% of your time and effort for investigation of 10% of the risks.

  1. I'm a bit concerned about this quote:

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.

"basing my request on fears" ... perhaps some of the team haven't bought into the notion of risk management? Risk management is management taking into account uncertainty ("fear" as a one syllable word lacks the dignity and gravitas of "uncertaintanty"). Whoever is making this complaint reminds me of the French quip, "That's all very well in practice, but how does it work in theory?" Your risk analysis has generated data that indicates that this is happening. That "should need less time" isn't translating to "does need less time". I'd recommend that you flip the script on whoever has uttered this quote. You've got evidence that repeated tasks are not leading to efficiency (I'd actually look for ways to quantify this and potentially develop it as a risk trigger/key metric). Work from your data; make your adversary back their claims with data.

While you're at it, have a frank discussion with this individual about another quote in your question, " 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." Your team is not learning fast enough; they're being hit by the same thing repeatedly. I suspect that when you learn to manage that issue (a certain risk is an issue), then you'll resolve a huge cluster of your associated/consequential risk. Understanding why this issue is happening is the real reason to practice risk management - to get ahead of the curve and respond to this while it is still a risk, and before it becomes an issue. (which is also the response to the "fear" challenge.)

  1. Some more quotes:

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"

These are good; they could be better. Personally, I find that I express the risks more clearly if I state them in a consistent way. "Given precondition if event then consequence" - I don't have full insight into the examples you cite, but they might be:

  • Given pressure to deliver on time, if we deploy code with live bugs then . . . " (I'm not entirely sure what the consequences of buggy code are, but they are probably an increase in technical debt/added work to the backlog, loss of customers, etc. Consequences should generally be something that can be expressed to a grandmother/stockholder in 30 words or less

  • "Given ??? If tests don't cover the full functionality, then ??? I'm not sure why this would occur - what is the customer/end user/business consequence of partial testing? (I completely and vehemently agree that partial testing is less than ideal, but what is the impact on your sprint, your ability to deliver value. At a minimum, I'd argue that it is more technical debt, but I think the more accurately you can express this the easier it will be to decide how much effort to devote to resolving it. The given may be unimportant here, or it may be the critical part. If the fundamental problem is that your scrum team lacks depth in QA procedures, that devs aren't writing comprehensive tests (or worse yet, are writing tests that don't test the essential behaviors), then you know how to mitigate this risk - and you know how to measure your success in mitigating the risk, and you know how to make a compelling case to management. "If we can train two devs in improved QA, then our test coverage will increase from X%, which will reduce the number of bugs in deployed code by Y%, which will allow us to transfer resources from technical debt to new development - it will be like hiring a new developer. " (the two devs are scrum devs, so are expected to cross train the team).

Summary - I think you nailed it with, "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?" - spot on! I hope that the suggestions above will help you to get from where you are to that well phrased final sentence.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.