0

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

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.

  • 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 '16 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 '16 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. – Barnaby Golden Aug 14 '16 at 10:30
  • Doing the right things is doing the things right. Yes you are 100% right. Really appreciate your answer. – Leron Aug 14 '16 at 10:32
1

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.

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.