Quality. It’s the first word on programme sponsor lists at the start of a project, yet it is the first word to be discounted in times of challenge. We’ve all seen the signs; timelines are stretched, missing features must be added to make it a ‘viable product’ (purposely lost the ‘minimum’ there for reasons I will come to), which then heaps additional pressure on to the development team.
Progress is temporarily shown, and the initial confidence of sponsors is given a little massage, but then reality strikes, the increased velocity in your development team uncovers a few shortcuts in due process (e.g. Unit coverage) or rather than seeking the usual clarification as to what a story or acceptance test actually means, the developer makes an assumption which then breeds a development cycle equivalent of Chinese whispers. For example the feature was designed one way, developed another, tested another, and then you end up with confusion, wasted resources and money and a product that isn’t viable. This invariably leads to an ever growing backlog of ‘must have’ requirements with the programme looking to reduce scope still further to make a delivery ‘on-time’, perhaps with the inclusion of a ‘hardening sprint’ which in laymen terms means “We’ve lost our way, we now need to work together on what we have to make it less ‘buggy’ so that it can go out to users”
I’m sure that the above example is common to many people, and has become commonplace in many projects, as perception is that now it is live, the reduced functionality works. In parallel promises are made to the stakeholders that there are ‘lessons learnt’ to be scheduled, but are they all implemented? The old adage of ‘if it’s not broke, then don’t try to fix it’ holds weight here, especially if we change a couple of the words “If no one has asked for it, then don’t try to fix it’.
More sticking plasters are placed over the cracks, and teams start believing their justifications for avoiding building repeatability through quality. As much as we hear; and as much as I believe in the ”self-organising’ team, I still believe that there is a role to be played by a QA Manager. A manager that understands development principles and can advise on best practice. Reviewing story development at the unit, integration and automation level to provide a view on quality. If the build reports kick up a number of failures in an area, you can deep dive into the problems. Is it technical, or is it comprehension and understanding of the requirement, can simple tweaks in procedure I.e. More time with product owner increase quality through understanding?
Reviewing automation coverage and results, may uncover key areas of regression that can be investigated, changes in error coding may highlight a break down in collaborative methods between your cross functional teams removing the impediment of unnecessary errors. Again simple remediation in the form of communication can have a positive view and output of quality.
How well have your testers been involved in the teams objective? Are you running small waterfall teams, where developer codes; check-in and QA picks up the story for testing without interaction? Working in parallel, checking and working through acceptance criteria will enable greater understanding and focus on Quality, if a problem is found the tester and developer can walkthrough the root cause and move to a resolution quicker, rather than a series of nightly builds until the message is understood. Again communication and collaboration can provide efficiency, with a quality focus.
Throughout this article, I have purposely avoided technical considerations, and yes I concede that collaboration alone cannot ensure quality, but if a technology choice is causing delays, what could have been done sooner to understand the limitations? I also mentioned earlier ‘Viable Product’ rather than ‘Minimum Viable Product’, the reason for omitting ‘Minimum’ is I believe it promotes a negative feeling from the start. If you then need to descope, how can you realistically reduce the ‘Minimum’ and maintain confidence in the product? If you deliver below the ‘minimum’ Product owners and stakeholders will need to ‘sell’ to the target users to ensure take-up and confidence is maintained. This is one of the reasons I like to change the perception at the start, removing constraints of ‘minimum’ and focussing on what makes sense with the resources available to make the end users daily life better.
Quality is key for projects, especially with respect to future phases of development. Perceived high quality products make future budget requests tenable a the benefits are understood and reputation is built. Quality through understanding, collaboration and commitment to reaching an end goal should drive confidence through your delivery team. Though not always easy to think long term when your team is up against it, delivery at the sake of quality is rarely a good solution long term and can often compound your problems as we enter a seemingly never ending feedback loop.
