For those unfamiliar with the term Entropy, it has its origins in Thermodynamics; commonly associated with the amount of order, disorder, or chaos. It is naturally unidirectional, moving from a state of order to disorder over time until the order reaches a state of equilibrium. As a trend, "Equilibrium Quality" seems to be the state where software products naturally move towards, which doesn't sound that bad, does it?
Every team is focused towards delivering quality, no one wakes up in the morning with an idea to introduce defects, we naturally ideate to solve problems. Unknowingly though, dysfunctions always creep in and identifying a dysfunction is extremely difficult especially when you are a part of that dysfunction. We've all been there and our context has defined our decisions; which cannot be challenged unless you have the exact same context. But there are common problem patterns that can be identified and the context can define the most acceptable solution.
I posted one such commonly occurring pattern on LinkedIn and my connections were gracious enough to help me with their views (you can check out the discussion thread here). What one will see is even though the problem pattern seems very common the solutions can be miles apart. None of these solutions can be challenged unless one has been in the exact same context. In the remainder of this article, I'll utilise the same problem statement from my LinkedIn post and discuss what I would do for this commonly occurring pattern based on my context definition. Hopefully, (my connections on this LinkedIn thread and) I help you make informed decisions based on experiences that have worked in the past. The problem:
The usual context #1: That's subjective based on the defect severity
The most widespread solution to this context seems to be defining the severity of this defect. If the defect tends to be a minor one then it can be deferred to a future sprint / release. In case it's a showstopper which hampers the working of the product, that's a no go. Next steps would be to get the Development Team and the Product Owner in a meeting and decide the outcome.
Reasoning against dysfunctions:
How does one define the severity of a defect? A general example would be that tiny cosmetic defects are minor whereas a logical defect is a showstopper. The Development Team and the Product Owner collectively define the severity of these defects to prioritise the order of fixing.
Here's my story, during the monsoons of 2009, I purchased my first motorcycle. Unfortunately it came with a defective fuel injection system, the engine used to shutdown the moment it rained and had to be replaced. In 2013, I purchased my first car and unfortunately, it had a dent on the bumper. I refused to drive out of the showroom unless it was fixed. Strange that as a user of the product, a cosmetic defect in a car was a showstopper for me even though it did not affect the working of the car at all. Why does the soft nature of software receive a special treatment?
Product Owners are the voice of the user and during a defect triage we believe that they are informed to represent the user's desires. How often does a Product Owner run through these defects with the users before deciding the severity (especially when the product is open for public use)? If you've ever had a stakeholder from marketing, attempt passing a defect as minor one where the brand logo is coloured #ee5643 instead of #ee5633.
What would I do?
A defect found during a sprint shouldn't have any reason to be deferred for the future. This decision is not subjective, these are objective decisions based on a non-flaky Definition of Done. A defect triage makes sense when production defects need to be fixed and an order of fixing is needed because of limited bandwidth of the Development Team. During sprints, it's a waste! Stories with known defects are not Done, period.
The usual context #2: The Product Owner is accountable
The most common solution to this context comes from the Scrum Guide, the Product Owner is accountable for optimising the value of the work the Development Team performs. Optimisation takes various forms; it may mean perfection (zero known defects) and it may also mean release yesterday (to gain a competitive edge). Based on the definition of optimisation, the Product Owner takes the final call that decides the fate of their products.
Reasoning against dysfunctions:
This seems fair, we've seen this happen, the owners are always held accountable for the actions of their teams. Be it the Apple Maps fiasco, or the list of Uber Scandals, or the very recent Facebook Data Leak. The Product Owners have always faced the consequences of their actions hence most of them are extremely careful to make sure that they make the correct decisions with regards to their products which includes allowing known defects. Isn't it?
I believed in this until 2017, then a Volkswagen engineer was jailed for emissions scandal. This was an eye opener because the judge acknowledged that the engineer was not the mastermind (Product Owner), he did not receive any special compensation, and was only being a loyal employee. This was a message to every employee and contractor around the world that each individual is responsible for their actions.
If it just crossed your mind that these measures are needed for critical applications only, think again, just like defect severity, how does one define a critical application? Banking, Healthcare, and Life-dependent usually come out at the top when we speak about critical applications; what about an online radio that plays in 256 kbps even after selecting 128 kbps, eating limited bandwidth? Or web pages that don't zoom for people with disabilities? Or grammatically incorrect error messages for people like me.
Why should one invest in a non-critical application?
What would I do?
I do believe that Product Owners are accountable for optimising the value of the work the Development Team performs. It's in the Scrum Guide after all, they are accountable for the final results. That in no way means that the Development Team is not responsible for the quality the product provides. Product Owners and Quality Engineers are not the Quality gatekeepers of a product, every professional is equally responsible for it.
And if the Product Owner for some reason pulls accountability as a reason to release with defects because meeting the release date is more important, what would it take for the Development Team to take a stand against it? After all, they can go to jail for it. And if it's poor release planning, then fix the release planning process; one dysfunction cannot be fixed by another dysfunction.
I'm the Product Owner of this article and the LinkedIn thread that sparked this article. Yet a couple of people asserted that I was unethical and not transparent with my intentions since I did not mention that I'll be utilising this thread while writing an article. If they knew, they would have chosen not to answer or answered differently. I wouldn't argue with that, may be I was unethical and not transparent; the way I saw it, the comments were already public, this article hardly mattered, so I played the devil's advocate instead, throwing more scenarios at them and making them pour their hearts out; I'm not taking credit for their views, I don't even agree with many.
Why do the tables turn with ethics and transparency when we release known defects? Just because we are not at the receiving end? Stories with known defects are not Done, period.
The usual context #3: Quality is directly proportional to cost
This is a known fact, as a user of products, I realise that in order to receive a product of a higher quality I'll have to pay more. A Rolls-Royce is costlier than a Ford. That's the constraints defined by the project management triangle. Especially for Fixed Time - Fixed Cost projects (my favourite types) defects are inevitable since there will always be a negotiation between fixing defects and delivering scope. That's the difference between theory and practice. Being on time is important and retrospectives help us improve for the future.
Reasoning against dysfunctions:
iPhones are high quality phones, it's a big brand, it's costly, and provides a very high degree of usability with iOS. Samsung Galaxy Note 8 is just as comparable, it's a big brand, it's costly, and provides a very high degree of usability with Android. So, Android vs iOS; which one's better? This is not a debate, both are awesome pieces of software. Having said that, I own a OnePlus 5, which is a big brand, provides very high degree of usability with Android, but it's only half the cost.
From a scope perspective, each of these three phones have the same features (scope, at least the Androids do) and these are released at more or less equal intervals (time); so the quality must be defined by the cost. But the cost of what? Both Apple and Google are known to employ the highest paid individuals who are committed to deliver the best software. Yet Samsung Note 8 costs more than OnePlus 5. There can be only one explanation, the cost isn't defined by the craftsmanship of the engineers rather the raw material utilised define the cost.
Difference in cost does not provide a leeway for the engineers to add more defects or find less defects. Engineers are highly committed, focused, and skilled craftsman who are dedicated to deliver the best; the raw materials though affects the quality (e.g.: the dashboard of Rolls Royce may be made of mahogany whereas the dashboard of Ford may be made of plastic). But what am I saying, an experienced developer must logically deliver better results than a newbie, isn't it? Let's define the raw materials for software craftsmanship: adequate training that up-skills engineers, latests bug free libraries, investment in information radiators, good management practices, etc. Your raw materials define your quality, fix these instead of negotiating with excellence; one dysfunction cannot be fixed by another dysfunction.
What would I do?
I'm bookish by nature and have heard a million times that there's a difference between theory and practice. The way I see it (and you should too), theory is someone's experience written in books (or any other medium). If you ignore this, you're missing out on the most practical experience you'll ever find. One doesn't need a retrospective to understand why a known defect was allowed in the code base. This is a pretty common dysfunction in the software industry and will continue to happen even after hundreds of retrospectives; the only way to stop it is to have a discipline to not allow this.
The project management triangle isn't incorrect, all you need to know is that the reason for poor quality cannot be an engineer's skills. For a committed craftsman, the scope, time, and cost can be negotiable; Quality is not negotiable! Stories with known defects are not Done, period.
Equilibrium Quality
This sounds like a good thing to have, until you associate it with entropy and that defines equilibrium as a state of Perfect Internal Disorder. It's the one thing that none should achieve with regards to quality. And since entropy results in moving from a state of order to disorder with time, your current order is a disorder of the past and your future order will be a disorder of your present, finally resulting in equilibrium (hmm, that sucks).
The only way to control the unidirectional behaviour of entropy is to invest very high energy that keeps the current order constant or reverses to an order in the past; the Perfect Internal Order. Every product will have a different state of order with regards to entropy and with every dysfunction the state will move a step towards disorder. Luckily, a simple high energy rule can reverse the effects of disorder - Stories with known defects are not Done, period.
I kind of lied when I said that your solution can vary with your context; when it comes to quality, there is just one solution - Quality is not negotiable! As long as you use this in any context, your product's quality will have a low entropy. Every now and then you may feel the urge to embrace dysfunctions and reason with it to justify your decisions. If you hope to be a highly ethical and transparent professional you don't need to convince anyone, you just need to convince yourself.
Acknowledgements:
This article would not have been possible without the active participation from my colleagues at ThoughtWorks, agilists at Agile Practitioners Group of India, friends at Wipro, Shell, Siemens, Cisco, and my valuable connections who contributed towards my LinkedIn post.