I was recently working on a project team of three: two developers and me. One of the things we had in common was that all three of us are perfectionists (in our various ways).
I noticed this trait in one of the developers early on: every button on every screen that he produced was aligned just so, the fonts were sized just right and the colours were the ideal shade. Similarly, the other developer enjoyed refactoring code just for the sake of making it more elegant; he loved the idea of working on a section of code for hours at a time to reduce it to just a single line. And I, the BA-cum-tester—if a system contained any defect, however small or esoteric, I rooted it out. Corner cases were merely a starting point for me!
This perfectionism led to us deliver absolute diamonds of features; between the three of us, we were producing an utterly perfect system. Which is something to aspire to, isn’t it?
Like every project, we were operating within constraints. In terms of the time-cost-quality project triangle, we were limited in cost and extremely limited in time. The business was desperate for a working version of the system we were developing: last year was too late (no exaggeration!). And, in this context, we were making quality the highest priority.
Luckily, we had a project manager who wasn’t afraid to shake things up when necessary. So, he made us all sit down and assess our performance to identify and fix the problems that were slowing us down. As a result of this exercise, one of the problems we found was our drive for perfection (naturally!).
For example, whenever a story was “developer-done” and passed to me for the first round of user testing, I would put it through its paces and pull it to bits. No defect was too small, no niggle too minor. And, the minute I found a problem, the developers would compete with each other for the chance to fix it. “Zero defects” was our goal!
Some days, we would find ourselves caught in a cycle of UAT – defect finding – defect fixing – UAT – defect finding – etc... with no development being done on new features.
No wonder we were delivering so slowly! Our perfect diamonds of features were being formed over near-geological timescales, just like actual diamonds.
So, we changed, and one of the things we threw out was our commitment to “zero defects.”
Defects were then put through a triage process. Did it stop the system running? Did it cause the system to produce the wrong result? Would it cause difficulties for the users? Would the end customers notice the difference? If yes, then it must be fixed, by all means!
On the other hand, was it just cosmetic? Did it only occur under extremely rare circumstances (just how often do all the planets align in a single line, anyway?)? Could the users still get the right result? Would the customers still receive the right information?
No one was saying that the system should have defects. We merely decided that some defects could be lived with in the short term, in the context of a system that must be delivered in working condition as soon as possible. We could (and would!) fix all defects over time. All we did was prioritize the defects that must be fixed now over those that could be fixed later.
And, if the users don’t notice, and the end customers don’t notice, and the system is fit for purpose, then who’s to tell whether it’s a rhinestone or a diamond? After all, rhinestones look just the same as diamonds... but they cost a lot less.
Don't forget to leave your comments below.
Simon is a Business Analyst with about 5 years' direct experience in the BA field, but he's a spent a lifetime gathering insights in careers as diverse as accounting and pizza delivery - and even acting! He's worked in both waterfall and Agile environments (and prefers Agile!), in large corporates as well as small businesses. He's always had the writing bug, too!
Comments