When introducing scrum into any workplace, many people have strong
opinions on what agility means and how we accomplish it. Some of these views create large divides between teams, sometimes just healthy conversation. People are understandably subject to their experiences and most experiences differ considerably from person to person.
Whatever your background and experience whether it be through a multitude of business domains, delivery models or practices such as waterfall or Agile, you will have habits and confidence around doing things that you are comfortable with. One thing for sure though is that bugs will always exist and problems will always arise, no matter where you have been or what you have been working on. If you don’t believe that is the case, you’re probably living in Utopia or have no concept of the software lifecycle whatsoever. If it’s the former, please tell me your location.
So bugs are bad, everyone knows that. Their very nature by definition brings negativity to what the bug is associated to including the people who near the area it has surfaced. In most environments this lowers confidence and identify’s and highlights what is known as failure. As such nobody wants to acknowledge existence of problems or bugs and in blame cultures they are often hidden to avoid accountability. Some company’s openly promote this culture by measuring quality by counting the number of bugs. I have even heard of companies who measure a software testers skill and ability by the number of bugs they find! Don’t get me started, thats a whole other blog post.
We need to build robust systems so we begin re-factoring processes, communicating and refining techniques, introducing quality enhanced practices such as TDD, pair programming, peer reviewing, setup continuous integration servers to visualise quality and automate builds. We also attempt to get clear requirements so that we know exactly what we need to build and build tests around the behaviours. We continue to improve the processes and practices to get on top of quality everywhere possible. These approaches work! They sure improve quality and provide a fast feedback loop in identifying issues when change is implemented. We do all this, because high quality, working software matters!
For a company to be agile, responding to change and arguably having the ability to release products and features quickly is crucial. Some will say this is the fundamental goal of being Agile.
Despite all this effort, a common problem I see is consistently dealing with bugs later. Opinion is drawn when a bug is found and sometimes treated with a low level of importance, an issue that can be dealt with later or an issue which doesn’t relate to the task at hand and can be thrown into the backlog. Sometimes this may very well be the best approach as it might fall in line with priority, but not always. A good example with this is when you may be working on a user story when a behavioural issue has been discovered somewhere else in the application. The focus or goal is not related to this affected area and therefore attributed with a won’t fix now attitude and worst of all hidden from decision makers responsible for the release. What does this cost?
This behaviour is symptomatic of target driven environments. The focus and reward is on a specific task and not on quality. Praise is given when a volume is measured and delivered. Therefore in order to meet the goal, a decision is made to separate the issue found from the task set. Although the known target will be met, the product in some cases could be compromised in terms of agility. Regular behaviour such as this adds a long tail of bugs over time and can put product releases at risk. Teams start adding hardening sprints to get back in shape, which can resolve the problem in some cases, but needs to occur often. Just like credit card debt, the more and longer you borrow, the greater the cost of repayment. This is the same when it comes to quality.
By creating a culture of bug tails, hardening sprints and pacified quality practices, agility can be compromised. Iterative development has emerged to have a mindset of being shippable at the end of each sprint. When this behaviour fails to occur, falling back to the core simple principles of agile can significantly help. This might be perceived as delivering less, but whats delivered is confidently working. Having 20 features confidently working in the context of the whole system gives a business the option to release and get value quickly. Having 25 features “delivered, but…’ isn’t the Agile way and puts a business in a fixed, weaker position.
Verification at the end of development is a common waterfall practice which has been proven to have, shall we say “problems”, particularly in the software domain. Therefore we should recognise when we do it and avoid it at all cost. To do this means getting everyone focused on quality and understanding how to tackle it. This means recognising that behaviours such as pressure on delivering by volume and metrics to support this can promote focus on targets instead of quality. This doesn’t necessarily deliver software quicker. I often say quality is the responsibility of the team and scope is the responsibility of the business. However everyone involved with the product has a role to play and contributes towards quality. A culture with this mindset will go a long way on helping and maintaining business agility,