When I was in class 6 and my brother was in class 8, every Sunday, my father would sit with us and challenge us for a face-off. One fine Sunday, this was our challenge- “You have five minutes to write names of twenty objects that you see around in the house. Whoever is the fastest, wins!”
We jumped at the tick of the stopwatch and started scribbling with the utmost determination to win. When the timer stopped, our father took both our notebooks to analyze and declare a winner. While looking at my brother’s handwriting, he squirmed and twitched his eyes, as if trying to adjust light to fill his iris with their correct shapes. While looking at my notebook, he smiled but grew disheartened when he realized I could only list down 12 (not 20!) names.
He rose from his high-back chair, took a deep breath and declared that there is no winner. My brother who had expected to win because he had fulfilled all terms & conditions dropped his jaw.
My father explained his decision- “(looking at my brother) You had accomplished what you were asked for, but it was hardly readable. I couldn’t understand most of the words and a few even had spelling mistakes. So, you need to work on your handwriting and spellings. And you (pointing towards me), you write well and your spellings are on point, but you need to pick up speed.
You see, whatever you do in life, you can’t let go of quality. And when you have quality, pace up so that you can beat others in the competition. Both quality and velocity are indispensable. You can’t just miss one and expect to win. If you have one of them, you’ll be average. But if you have both, no one can beat you! So, let’s meet again next Sunday with 30 words. Alright?”
Decades later, I still remember this story vividly. The lesson which my father taught us about quality and velocity is precious and still stands true.
The reason why I am nostalgic about all this is that recently I was hurled into an age-old debate of Quality v/s Velocity in my team. I wanted to tell them this story, but before I could do that, people convinced each other, found a middle ground and safely hush-hushed the topic for the next meeting.
This isn’t new. And our people aren’t the only people who do this. It’s a very common problem and since ages people are struggling to overcome this trade-off.
What troubles me is this- is there really any trade-off? Who would have been the first human to convince the other that it’s okay to delay the ship date or okay to deliver a bad-quality output, and call it “done”?
While this might be a way too harsh thing to say, especially in the extreme-agile setup these days. We all know that things go wrong, unforeseen circumstances appear, requirements change and as a result, deadlines had to be pushed ahead. But does it have to be a necessary evil even in the most perfect situations?
What happens when you compromise on the Quality?
When you compromise on the quality, you lose the trust of your clients. No one wants to go to the market with a cranky product. If you think that the product would have been better had there been more time, then you’re at fault for not setting the expectations right with the product owner.
On the contrary, if you had set the right expectations but timelines were hurried from the client’s end, then you should proactively convey the downsides of delivering a low-quality product. While the client would always be in a hurry to launch the product into the market, it’s you who has to make sure that the client understands that ‘re-engineering’ is a costlier option than ‘development’ and it slows you down, even more, when you really need to pace up as more users join your platform.
You need to understand that great products are built when you make quality an integral part of the development process. The product can be scaled in any direction only when you have achieved a desired level of quality. So, even if you are in a hurry, go with fewer things better, rather than doing all things with low-quality!
What happens when you compromise on the velocity?
In an increasingly agile world, founders are struggling to make their idea flourish. Therefore, they go by an aggressive deadline because the time to market is important for them. If they don’t hit the market at a suitable time, one possibility is, they’ll lose their business to some other competitor.
Moreover, investors start getting anxious if they don’t see any ROI. As a result, founders need to get to market fast i.e. before anyone else hits the market with a similar idea.
So, when you compromise on the velocity, in a way, you hamper their spirits and growth model. You weigh them down with your death march to deadlines.
So, what’s the solution? Can we have both?
Certainly! I mean, why not?
But where can we start?
Start with Agile.
It not only gives you a chance to keep a balance between both the things but also makes things a lot more efficient. How?
Here are some of my thoughts-
- Delivering the fully tested features in chunks helps you to keep a fine balance on both Quality and Velocity.
- You can set the quality benchmark for every release which ensures that you don’t ship a substandard quality.
- You can also set the release cycle as per the requirement which helps you control the anxiety of going to the market fast. You can choose only a set of features that will go in the first release and keep your focus on quality intact.
- As you move ahead, you’ll gain a better understanding of how things work, where the team gets stuck the most and time estimation on each story point. So, with experience, you can increase the focus on any area as per the requirement.
Even if nothing works in your favor (you’re a small team or you’ve just launched your startup), I would say that start with quality.
An organization called DevOps Research & Assessment have come up with an interesting theory (based on their research since 2014). The theory says that “The engineering teams that focused on quality are the ones that gained speed.”
That means, once you’ve built your “quality” muscle, it’s easier to train your “velocity” muscle.
A lot of people will say that it’s nearly impossible- that you can’t always root for quality.
I agree! There might be some cases when you are not sure what you’re building when you have a vague idea but you want to test it out before going all in. In such cases, quality comes second to speed.
But other than that, there’s no way that you can compromise on either quality or speed. Both of them must go hand-in-hand.
I really hope this blog gives you a better perspective of how small things make a big impact and help you understand why quality and velocity are too important to be interfered with.