Forem: Dhruv Agarwal

5 ways to skip QA approval forever!

Dhruv Agarwal — Thu, 04 Jul 2024 13:07:39 +0000

3 days of planning, 5 days of execution and then the whole work gets stuck for weeks on QA. On the flip side if it gets picked up, it results in a poor job of testing leading to a reactive firefighting later.

Does that sound familiar?

Well that was atleast my team’s state at Shuttl for every new feature our devs picked. No matter how big or small, the QA was the bottleneck for every change.

It was unavoidable because in the absence of the QA, the quality risk was even higher.

Nobody likes firefighting consistently. So, what’s the fix?

In this blog, we’ll talk about 5 steps (in order) which will help you get unblocked from a QA approval:

Shift Left when QA gets involved
You code it, you own it
Always have their back when needed
Look back to find improvement patterns
Get inspiration from industry benchmarks

Shift left when QA gets involved

A typical development process starts from planning, then you program it, test it, release it and monitor incase of any failures. (as shown below)

In a typical software team, there are multiple engineers building features however 1 or 2 manual QA attached per team(or pod). Once the features/bug fixes are ready by the devs, the QAs are responsible to do systemic tests to ensure correctness and then it is released.

The problems occur when multiple features have to be released together.
That’s when the QA bandwidth gets crushed in toggling between different features.
That’s when the development team despite having a ready feature gets delayed to production.

Cherry on top is: after a long wait, there is a feedback and then again a long wait - so the cycle continues!

To fix this, the first step is to shift the QA towards the left in the process.

Instead of them testing the changes manually, ask them to create a test plan during the planning of the feature

Test plan
A document which consists of all scenarios where the product should work, all corner cases and cascading risks covered.

Since, the QAs are specialists of thinking about the corner cases, freeing them up from the grind will enable more quality and coverage in the test cases.

Once, the test plan is ready, we move to the next step ⬇️

You code it, you own it

We developers are more than able and smart to run everything end to end. The test plan takes the load off of thinking sad cases and now all we have to do is check, check, check

One of the benefits of having a test plan before programming is that you can fix your design in accordance to the test plan itself and save many days (and nights) from your life.

So, now nothing stopping you!

Always have their back when needed

However, life is not so ideal. And sometimes you might need to make fake data, set up new environments or knowing additional context which might totally derail your flow.

Then is the moment where you must remember QAs are our team mates 😄 and inform them beforehand what test plan items might require their help so that when you’re ready to test, they can support you with activating those activities.

Common ways to involve them in:

Mark the items in the planning stage itself
When you are about to finish development, book their time in advance to get your environment ready
Request their help in your stand-ups

Look back to find improvement patterns

Throughout this change, there will certainly be different phases of problem:

[Pre Change] Lot of time spent in just waiting for QA approval
[During Change] Teething issues and process adjustment to your team’s comfort
[Post Change] Iterations to find what can be improved to achieve your peak productivity as a team.

One practice that will always help you will be doing a retrospective after every sprint basis on actual data (as below)

Collating data can be time consuming and hence has a risk of de-railing all retrospectives.

(Disclaimer: I am also the co-founder) A tool like MiddlewareHQ helps you be focussed on your work by bringing all the process insights at one place from your tools like Jira, Git, etc.

Consider this as a fitness band for the whole team while the athlete (the team) is training 🏃🏼‍♀️

Get inspiration from industry benchmarks

We as software engineers have grown up looking at technology benchmarks and language benchmarks. However, when it comes to our productivity, there’s no standard practice.

QA being a bottleneck is one of the many challenges in your software delivery journey.

A great way to keep improving(IMO) is to leverage the industry benchmarks for teams like yours. DORA metrics is a great framework by Google and they publish an annual report every year with benchmarks on delivery process and quality. (Read more about DORA metrics)

That was the aim with which we decided to launch an open source offering to measure DORA metrics for any team in the environment of your choice.

Our mission is to remove friction out of the development process and enable builders to build better! Do consider giving us a ⭐️ if you like what we’re building!

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

Middleware is an open-source tool designed to help engineering leaders measure and analyze the effectiveness of their teams using the DORA metrics. The DORA metrics are a set of four key values that provide insights into software delivery performance and operational efficiency.

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

All the best and hope nothing blocks what you want to achieve!

Write Less, Fix Never: The Art of Highly Reliable Code

Dhruv Agarwal — Mon, 17 Jun 2024 11:14:20 +0000

If you're a developer tirelessly pushing out new changes, only to be dragged back by errors in your past work, this post is incredibly relevant for you.

Over the past decade in software development, one of the key mistakes I've made and seen others make repeatedly — is focusing on doing more work rather than ensuring the work done (no matter how small) is robust and will continue to work properly. These recurring errors can significantly hamper productivity and motivation.

From my own share of mistakes, I’ve learned valuable lessons. Here, I’d like to share a few strategies that will not only help you ship robust software but also free you from the shackles of your past work.

We will talk about the top 5 strategies that worked for me:

Plan for 10x
Psst: Your old work got a bug and is calling you back
Make the Systems Work for You, Not the Other Way Around
Always Answer with a Link
Understand software building is a team sport.

1. Plan for 10x

There are two types of engineers IMHO: those who hack their way through for today and those who design for the distant future. Neither approach is sustainable on its own.

Your code should be able to handle the growth your business is about to experience. However, over-designing for future challenges can lead to unnecessary complexity. There's a term dedicated to this - Bike Shedding

Here's my practical rule of thumb: plan for 10 times the current scale or consider how much your business is expected to grow in the next 2-3 years. Ensure your plans align with your business goals.

For example, if you're a cab company designing a booking module, and today your company handles 10,000 rides a day with an expectation to reach 100,000 rides a day in 2 years, use that as your benchmark. Designing a system for 10 million rides a day when you're only doing 10,000 rides might result in an overly complex and expensive solution.

2. Psst: Your old work got a bug and is calling you back

"Days and weeks of debugging can save you a few hours of writing tests" - someone wise.

Shipping code without testing all the edge cases is like a spray and pray strategy. The simplest way to ensure your code works as expected is by adding unit tests. This might sound obvious, but the importance of thorough testing cannot be overstated.

Unit tests not only act as the first line of defense against obvious errors but also serve as insurance for your code against unintended changes that could violate business requirements. Hence, reducing those adhoc bugs being assigned to you every sprint 😉

A trick for the lazy (like me): Before you write the code:

Write tests covering every corner case you can think of.
Pretend you're trying to break someone else's system.
Write assert False in all the tests and run them.
Naturally, all tests will fail.

Now, just work towards making each test pass. This approach takes less time overall and produces robust code every time!

3. Make the Systems Work for You, Not the Other Way Around

One of my managers once gave me the most impactful advice: "Act, don't react." This advice came when I was constantly being tagged on different Slack channels for problems, customer complaints, and payment failures. I was just reacting to each request, having no clue what might happen next.

That's when I started asking three questions for every feature I built:

How will I know it's working?
How will I know it failed?
How will I know it succeeded?

I then answered these questions at every level (feature, screens, app) by sending metrics to our APM tools like Datadog or NewRelic.

After setting this up, I configured alerts to notify me if anything went wrong.

By doing this, I became aware of bugs before they escalated into major issues, preventing reactive measures, poor customer experiences, and my own uncertainty about what might come next.

Start answering these three fundamental questions every time you build something to ensure you always act instead of react.

4. Always Answer with a Link

Just like bad work gets you tagged on various Slack channels for fixes, great work gets you tagged for context in areas you've worked on.

This can drain your energy when you least expect it, or worse, it can make you the go-to person for the same tasks because you know the complete picture.

Keep this secret trick to yourself:
Document everything. Include the context, architecture, and business-specific decisions you made while building the feature. When someone asks about the context of an area (feature, screen, app), just send them the link to the updated document. This will save you a few hours every time.

Additionally, thorough documentation makes onboarding new team members easier and ensures that your work remains accessible and understandable over time.

5. Understand software building is a team sport.

Software engineering often emphasizes the individual contributor path. However, reaching the end goal alone is impossible—you only reach it with your team (and vice versa).

Understanding and adopting a process excellence mindset helps you leverage the team's collective productivity.

Sorry for that worded statement 😄
To simplify, ensuring that reviews, deployments, and any collaborative activities involving code don't have significant wait times boosts your productivity immensely!

The best way to identify high waiting or blocked times in your team is to measure DORA metrics. You can use an open-source tool like Middleware, which provides DORA metrics out of the box.

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

PS: I'm also co-founder of Middleware and our mission is to make engineering frictionless for engineers. Do consider giving us a star if you like what we've built!

Ship code like a boss!

By adopting these suggestions, you can significantly reduce the time spent revisiting and fixing past work. This will not only enhance your productivity but also ensure that your focus remains on innovating and delivering new features.

Be productive, not busy! All the best 😊

Top 5 Mistakes Engineering Managers Do 🤦🏻

Dhruv Agarwal — Tue, 11 Jun 2024 07:08:44 +0000

Just became a manager or aspire to be one soon? This post might save you a couple of weeks by bringing you insights and learnings from other engineering managers’ mistakes.

In my past two companies, I’ve had the privilege of leading an engineering team. During this time, I experienced and learnt from the common mistakes that managers tend to make. Believe me, it can drastically hamper the team productivity and growth. When I started Middleware, I was fortunate enough to interact with 100s of engineering leaders and learn from their experiences.

In this article, I’ll be sharing the top 5 mistakes engineering managers make and their possible solutions.

Let’s dive right in!

Mistake 1: Macro management first, Micro management later

Every manager starts with high trust on their team. Hence, they start off by purely delegating the tasks to the report assuming it’ll be done. However, it is not un-common to get blocked or stuck during execution of the task. In the case where a manager is oblivious to this blockage, they only get to know when the task is on a delay.

That’s when they panic and start micro managing because now they don’t trust. Of course, this lack of trust does make their people unhappy(even more unhappier than they were happy) leading to burnouts.

Hence, always..

“Trust, but verify”

What you can instead do is, micro manage first and macro manage later. Here’s how:

Create a detailed plan with the team
Bring a consensus on a timeline which they believe is right
Now, always follow up on the execution of that plan and be available to unblock them whenever they need you
This makes the discussion objective and constructive than a blameful one and hence fosters more trust and ownership in the team.

Mistake 2: Never say “No”

Said yes to ad hoc tasks every sprint and now you can’t seem to complete the spilled tasks?

This is what you call a negative spiral. I’ll give you an example of our team’s early days.

A few sprints back, my team was working constantly while still spilling their planned work. They were starting to feel burnt out and that’s when I observed the sprint flow below.

Our ad-hoc task % was rising sprint on sprint and that made our team de-focus from the planned work, resulting into spillage and hence missing the product delivery targets.

Solution: We put a threshold of 20% on the ad-hoc tasks. This meant, we dedicated only 20% of our effort towards ad-hoc. Anything beyond 20% was alarmed(by Middleware) and said “No” to those tasks. This reduced our planned task spillage and also team burnout. A tool like Middleware can help track this

The result of it? Our product delivery became more predictable.

In fact, in the sprints where there was no ad-hoc work, we started shipping tech level enhancements more!

In all, I’m glad we started saying “no” beyond our threshold. It’s simply because it was not aligned with our goal.

Mistake 3: Become the most important person in the room

If you think that you are the most important person in the room, it’s time to flip your perspective.

Instead of being part of every discussion, empower the team to run without you. It not only enhances productivity of each team member, but boosts their morale too! As a bonus, you also get time on your hands to make other vital decisions.

Now, how to relinquish control when all you have been doing is ensuring that you are part of each and every discussion?

Let’s talk about this with the help of a common example:

The majority of meetings on your calendar are product discussions with the team where you also need to give approval on what is supposed to go as a part of development.

Till now, you were conducting meetings to give your context. Now what you can do is to just pass over a note of context and expected outcomes to the concerned team members.

To prevent another open discussion, the devs can use technical documents to achieve success.

Lastly, in case there is any context missing, you can write it in the same doc itself. Easy-peasy, right?

Mistake 4: Expect the product managers to give perfectly written tickets

Chances are, you must have faced these situations as an engineering manager -

“The team is blocked because the stories didn’t have the details”

“The stories have the edge case missing, please revert on those”

These scenarios block product delivery.

To avoid the above situations from occurring, an engineering manager should not directly pass the user story written by the product manager to the engineer.

Instead, you should sit with the product manager and refine these user stories to add engineering details like constraints of scale and the expected deliverables. You should also break down the user story into atomic deliverables.

I call it the “pre-planning” stage.

After this, the developer gets the complete context and they can then act upon these atomic deliverables.

The advantage of this entire practice? It saves tons of back and forth.

Pro-tip: If you’re able to break down the user story into independent tasks, you can also get them built in parallel. Doing so will decrease your time for delivery.

Mistake 5: Have different definitions of “Done”

Let’s admit it — We all have faced this at some point of time in our work journeys.

Having different definitions of “Done” can lead to no or delayed delivery to the actual customer. Hence, it becomes more important than ever to ensure everyone you are working with is on the same page with what “Done” actually means!

“Done” means released to the customer. That’s it, that’s the definition it should have.

Pro Tip: As you know, multiple team members are involved on one particular feature. What you can do is, create a primary owner for the feature. This means, this person will communicate about the feature’s progress on behalf of the entire group. The benefit of it all?

Apart from fostering a sense of ownership among your team members, it will also highlight the visibility of your team’s efforts.

Bonus Mistake: Only focus on tickets and not on development pipeline

A lot of managers end up only doing general management focusing only on tickets, making excel sheets and manual follow ups with the team. Engineering is one of the special teams whose most operational work is digital and most of the times the productivity gains are hidden in the simplest of things - PR review delays/rework, deployment pipeline being slow or errors pushing back our team from working on new stuff - Essentially key stages of shipping software once planning is done.

As an engineering manager, you can do much better! You can take care of the small things like these processes and the big things(delivery) will fall into place. You can use a tool like Middleware for measuring the pipeline improvements for your team using DORA metrics!

middlewarehq / middleware

✨ Open-source DORA metrics platform for engineering teams ✨

Open-source engineering management that unlocks developer potential

Join our Open Source Community

Introduction

They are:

Deployment Frequency: The frequency of code deployments to production or an operational environment.
Lead Time for Changes: The time it takes for a commit to make it into production.
Mean Time to Restore: The time it takes to restore service after an incident or failure.
Change Failure Rate: The percentage of deployments that result in failures or require remediation.

Table of Contents

Middleware - Open Source

View on GitHub

Say goodbye to manual follow ups and never ending RCAs, welcome a process excellence mindset which will help you add method to the madness 😄

Learning from the mistakes!

Since there is no silver bullet to engineering management, every manager has to pave their own path. However, it helps to learn from the common ‘eeks’ and ‘oops’ of the people who have walked this path before you.

Hope you recognised some of the mistakes you would have encountered, let me know in the comments 💬

If you’re interested to know the next 5 mistakes, comment on this story and as we hit 5 comments, I’ll write the next 5 mistakes and their remedies ✨

An open source Spotify-like yearly recap using your Github contributions

Dhruv Agarwal — Tue, 12 Dec 2023 19:49:51 +0000

Hey there, Dev Community!

You know that feeling when Spotify drops your annual Wrapped? Well, imagine that, but for your GitHub grind. We've crafted Unwrapped, an open-source tool that takes your year of commits, pull requests, and code adventures and transforms it into a neat, personalized recap with pop references.

What's the Lowdown?

Think of it as a summary card highlighting your coding journey. It compiles your GitHub activity - from commits and code stats to your reviews. It's like a snapshot of your year in code!

Why It's Worth It:

For us devs on Dev.to, this tool is a bit more than just numbers. It's a pat on the back for your hard work, a reminder of your wins, and a way to celebrate your growth. Plus, who wouldn't want to share a slick summary card with the coding crew?

Take a Peek:

Join the Collaboration:

This tool is a team effort! It's all about open-source love and community collaboration. Jump in, help us refine it, and let's make this tool even better together!

Wrapping It Up:

Ready to revisit your coding journey? Our GitHub-inspired recap tool is your backstage pass! Relive your milestones, acknowledge your progress, and why not, show off that recap with your fellow developers.

Cheers to your amazing dev journey in 2023. Hoping you like reflecting on it using Unwrapped. Do share your feedback, it matters!

If you liked using the tool, you can also look around and contribute to our open source repo