Low impact software issues might reveal high impact process issues

Sometimes, a problem in a software development process or in the ways of working can cause some types of issues or bugs to occur continuously. If they each on their own have low impact they might be given a low priority, but over time they might accumulate to become a problematic amount. Therefore, it can be worth to also investigating the lower impact issues to understand why they occurred.

An example of a low-impact issue comes from a project I was working on; it was found during the development of an automated check:

‍

Bug: A button becomes partially hidden at the bottom of a web-page when a certain number of entries is entered into a list that is displayed at the top of the page.

‍

The button could still be pressed so the impact of the bug was low (which in my opinion was correct) but I started to think about why the issue had occurred at all. It could, and should, have been caught before the story or feature was considered “done”. It was obvious too see if you filled the box with the amount of items we expect our end-users to have. Instead, it was caught after delivery which was expensive because of the following reasons:

‍

• It delayed development of automated checks.
• The tester needed to spend time investigating the issue and getting feedback from a UX/UI expert.
• The bureaucracy of filing the bug report and prioritizing it required extra time for the tester, team and developer.
• The feedback loop to the developer was long and required extra time from the developer to get up to speed with the code again.

‍

However, it occurred to me that if our process or way of working continuously creates these types of issues it might become significantly more expensive to fix in the future. An customer might not have a problem to use a work-around in one or two cases, but if there is a need for this everywhere in the workflow then it might become a major problem making a bad impression on the customer. In a worst-case scenario this may lead to the customer looking for alternatives to our software.

‍

Thoughts about a root cause in the process

I asked myself if the root cause for the issue occurrence could be one, or all, of the following issues with the process or our way of working:

• Lack of knowledge about business/use-case?
  Did the developer not know how many entries were expected to be put into the page in a normal workflow? Is there a disconnect between the developer and the end user so the developer doesn’t know what a common use case for the page looks like?
• Lack of access to the right competence?
  Why didn’t anyone else see this at an earlier stage? Does the team have access to UX/UI specialists that can take a look at visuals before considering the story/feature to be done? Was there no one at the feature-demo that spotted that the number of entries demonstrated was far fewer than in the use case, potentially suggesting this to be tested before being “done”?
• Lack of proper test setup?
  Is there a difference in hardware setup, the screen size and resolution, that made the error obvious in one setup but not on the developers’ setup?
• Lack of testability?
  Is it cumbersome to set up the test for the developer? Is it hard to deploy and test? Do we lack realistic test data?
• Lack of right quality mindset or culture?
  Was the developer or the team pressed to deliver code faster and therefore did not feel empowered to do the tests they would normally do (or want to do)? Is there a culture where the developers are considered “code monkeys” and shouldn’t do basic tests?

If any of the above is a root cause, there is a risk of ending up with a number of low impact issues (if not addressed because of the priority) that eventually makes the product polish crumble, killing the customer experience with a thousand cuts.

‍

‍

At the time of writing, I found for this particular example, the root causes were a mix of everything above and it was valuable to have done the digging.

• The UX expert had not been involved during development and now took action to work closer with the team to avoid similar issues in the future.
• It was revealed that there was a general lack of understanding of the end-user and the surrounding context. An initiative was started to give the team members access to this information. The first action was to start to invite people with deeper knowledge about the end-users to share how the product is intended to be used.
• Based on the knowledge sharing about the intention is create actions to acquire a better set of test data and better test setups to make it easier for the team to perform better testing.
• There was a previous initiative to improve the sprint/feature-demos that now got extra attention to make sure we have people with the right knowledge in place to give valuable feedback.

Hopefully these actions will help prevent future accumulation of similar kinds of issues because it most certainly would have continued if the flaws in our process would not have been addressed.

Summary

It is always a good idea to ask why an issue occur, even if it has low impact. Identifying and correcting an underlying problem can save a project from an accumulation of low impact issues that might over time become a major problem. If these issues are ignored, due to low priority, the underlying problem with the process or way of working might not be understood before becoming expensive to solve. Make sure not to neglect the lower impact issues, they just might help you uncover a high impact process issue before it creates a problematic number of issues.