A Great Developer’s Secret to Better Quality
I am not the great developer mentioned in the title. I have had the good fortune though, to have worked with many great developers throughout my life. This is a little story about what I learnt was a great developer’s secret to delivering excellent quality, consistently.
In one of my very recent projects, I was working as an offshore product analyst with four different teams with two to three developers in each team. I was a product consultant for three of the teams and the proxy product owner for the fourth one which was also the core product team. We followed Scrum (almost, not perfectly- more on that some other day). The non-product teams- let’s call them implementation teams, used to deliver an average of 11 story points, spread across 3 or 4 stories. The product team had a velocity of 14 delivered over 4 or 5 stories. Each iteration was for 2 weeks for every team. In order to track quality, one of the key metrics the project used was the defect reopen count and overall defect count per story. After 6 months of development and releasing various features and enhancements, we had enough data across all developers to gather some insights.
It turned out that one particular developer ranked significantly better than all the rest. By a great margin as well. Not only she had only 3 bugs reopen in the 6 months frame, but she also had a mere 13 raised over all the stories she had done.
That was quite impressive! The runner up had those figures at 18 reopens and 31 bugs. What was more interesting was that, this developer , Winnie, had one of the least years of experience in the entire firm. Winnie was known to be pretty smart, hence everyone just assumed that the great quality must be a result of that. This is where I wasn’t entirely convinced. I had seen before that great quality doesn’t just come from skill, but it comes more from good processes and practices. I was sure we were missing something here. I did the obvious act of asking Winnie what her secret was and she just sheepishly said, “I don’t know!”
A few months later (the developer continued her quality streak unchallenged), I visited the office where all these teams were located. It was a brilliant 3 month stint, and the energy of every team clocked higher, while we brainstormed on user stories, created iteration plans, planned releases etc.
One of the routine things I had to do was discuss the user stories with the developers and one of the things they did was showing me and the quality analyst, a demo of the stories before they pushed them for testing. As fate would have had it, one day I was perched over Winnie’s neighbour’s desk looking at a user story demo. After I was done and was chatting with the neighbour, I noticed something on Winnie’s computer.
An Excel file! What is a dev doing with an Excel file- I thought to myself. Most devs didn’t even have Excel on their systems and used the Office suite online. Winnie scanned some rows from her file, switched back to the browser window and clicked at a few places. She repeated that a few times and then changed the story status on DevOps to “Test demo ready”.
My eyes lit up. I abandoned the peeking and swivelled the chair to her desk and asked her,
Me: “What did you just do?”
Winnie: “You mean, testing?”
Me: “Yes”
Winnie: “Oh, I ran my tests before signing the story off from my side”.
Me: “What do you mean tests? Unit tests?”
Winnie: “No.. unit tests have passed obviously. But I also ran some user tests based on the acceptance criteria. I create some scenarios based on the criteria and I run them quickly”.
I was smiling wide. The secret was out!
Me: “Can I see that file please?”
Winnie: “Oh no. That looks ugly.”
Me: “That’s fine. Please, if you don’t mind”
The Excel file was indeed not a pretty sight. It was quite hard to understand at first the rhyme or reason behind what I saw. But on a closer look, it seemed apparent that Winnie had mapped some cases from the acceptance criteria and had created a few scenarios. For example, if one of the criteria said that the loan to asset value ratio must be lower than 50 percent, Winnie had three scenarios of loan and asset values written, <50, >50, =50. Almost exactly as a tester would do. It also came full circle when I thought of the Sprint plannings and backlog grooming sessions- Winnie was always asking how we would test something, sometimes more than the testers.
I asked the final question, “Did anyone teach you this thing you do? How did you think of doing it?”
Winnie looked up in the air and thought of a good answer. “I think, it is a bit of pride and laziness. I really want to be proud of what I send to you or Chandni (the QA) to test. I don’t want to live in fear whether what I released will blow up somewhere. Second, I really want to work on other things or go home once I am done with a story. I really hate having to work with the same story, again and again and again when you folks find bugs”. I nodded and thanked her, having learnt an excellent lesson on quality. Winnie had created her own simple and powerful way to ensure that her own work stayed the minimum and never expanded.
In Agile, I have heard that we need to complete the minimum to deliver the releases for quicker learning and better planning. I think folks like Winnie really espouse that principle and in doing that, they paradoxically deliver better quality and not worse.
