The Frog, the Software, and the Quality
Somewhere, somehow, you may be heard the boiling frog metaphor: “if a frog is put suddenly into boiling water, it will jump out, but if the frog is put in tepid water which is then brought to a boil slowly, it will not perceive the danger and will be cooked to death.” [1]
Well, to be honest, Science showed us a long time ago that real frogs are a little smarter, and they will try to escape when the temperature goes uncomfortable.
However, the metaphorical boiled frog is still useful to introduce you to a real problem: “the difficulty of responding to disasters that creep up on you a bit at a time” (Paul Krugman). And it is useful to provide some insights about how to avoid reaching the critical discomfort point of no return.
Plus, frogs are really, really cute :-)
Let’s do a little step aside, and move from frogs to the software industry. Contrary to what you might think, building up a piece of software is less scientifically rigorous than you can expect. Or, at least, it is more driven by “individuals and interactions” than by mathematical formulas. Software, in fact, is developed by humans which interact with other humans, humans with different skills and knowledge, working together towards a common goal: provide value to users.
Nowadays, users are more and more hungry for value. And not just value as working software, but also value as software that is simple to use. And fast. And safe. And pleasant. In one world, your software must have “quality”.
Obviously, you must continuously provide fresh and new high-quality value to your users.
The only way you can keep creating value and ensuring quality is by creating a culture of quality within the all teams involved with the product, so that people become passionate about quality as a personal value and embody it in all their actions.
But as our metaphorical and mythical frog in tepid water, it is really simple to miss when your efforts to quality erode a little, bit after bit. Someone calls this phenomenon “creeping normality”.
Fight Fire with Fire
When your weekly activities revolve around implementing new cool features and fixing the few insidious bugs that popped out in production environment, you may miss the time, priority, or workforce to take care of the little, annoying glitches that passed unnoticed or underestimated.
Sometimes, somewhere, the only option for people involved in testing or QA would be to file a bug report, lower priority, and wait.
At Casavo we aim for a different approach. And being in the quality guild of Tech and Product teams means thinking outside the box and use insights from other disciplines to identify the issues that we are experiencing as a team and to nurture our improvements.
So we framed a specific topic: we want Casavo’s UI/UX to always be of excellence and we do not want small defects that can be easily fixed to degrade the user experience.
And we framed a specific team hitch: we want the team to be able to counteract the potential inattention to these small defects, perhaps because they are considered less priority than more urgent business objectives.
Then we started an experiment: The One Hundred Papercut.
The One Hundred Papercut Experiment
The experiment name is a tribute to a similar initiative from the Ubuntu community.
By now, we are classifying as “papercut” small defects in UI/UX on production software that:
- must not prevent the use or return incorrect results (in this case it is a Bug)
- must be easy to fix
- must potentially be encountered or noticed by many users
This new issue type is helping us to make these small defects visible to the whole team — not only to our designers — and manageable. In fact, we don’t want papercut to stay dormant in our backlog, but we want to make them first-class citizens of our bi-weekly sprints.
The experiment is still ongoing, and we are still exploring and course-correcting to reach the best management of those issues.
We initially found that although a papercut is simple to correct by its nature, or at least is should be simple, it may need its own story points to help in the sprint planning phase.
This leaded us to investigate how the papercut experiment can be best fitted into the Scrum framework. Our crisp agile coach helped us to understand that while the idea of papercuts as backlog items distinct from bugs or user stories is a plus — a papercut contributes toward a change/improvement and is highly refined — we were lacking in the process of placing those items into the backlog itself.
A better approach would have been to team-work on the clarification and contemporary writing phase of the backlog item, not only to immediately avoid the use of the backlog as a collector of lost memories, but also to stimulate collaboration in the phases of clarification and simultaneous shared writing shared of the item. This approach can be more effective and can help to consolidate the teammates’s relationship and may produce backlog items that are ready for the Product Owner prioritisation activity.
Of course, while our initial and tactical goal is to have a practical framework to enhance and protect the experience of our end-users, we also want to leverage this initiative to start instilling the culture of quality, bit by bit.
The same way you can go down by “creeping normality”, we want to raise up with “climbing excellence”. By taking care of the visible external quality of our software products, taking care of consolidating our test coverage, taking care of reducing our CI build failures — a little, simple and rewarding step at a time — we may lead in the long run to huge improvements and, in the meantime, as a team, we may internalise habits and create a solid quality culture.
Stay tuned and save the frog!
