Fixing our agile practices

Umair Mohammad
3 min readSep 23, 2021
Scrambled sticky notes scattered on table to convey broken agile practices.
Photo by Ferenc Horvath on Unsplash

In this blog, we’ll be discussing how to identify a few misalignments in our agile practices, its consequences and how we can fix them.

Our goal is to be encouraged enough, to start taking initiatives to re-align our team, by the time we complete reading this blog post.

Quick back story : Couple of months back, I have joined Ninja Van. I had an amazing onboarding experience. At the same time, I also felt my team is facing few hiccups. So I took it as a challenge to fix them.

Problems are not allowed to accumulate — XP

Extreme Programming Explained by Kent Beck helped me in understanding the practices better and encouraged to take initiatives.

For the sake of example, let’s discuss few relatable scenarios, initiatives taken and their outcomes.

Support tickets ✉️

As soon as I joined the team, my teammates invited me to relevant groups. One of them was technical support channel.

First few weeks, I spent observing the types of tickets being opened. They were pretty straightforward ones. For example, a certain API was throwing an error for a certain scenario, etc.

Though the tickets creation rate was not extraordinary, still we felt there are some space for improvement.

After reviewing the frequently repeated issues, we understood that most are very simple scenarios. Our automation test should have caught this before release. Looking into the test suite we found out that few scenarios were unstable and few where to be added. Instability was mostly due to asynchronous behavior of our code flow.

Test : Early, Often and Automated — XP

So I made it my personal goal to fix the automation test, bring it into our build pipeline, with appropriate trigger & alerts. And eventually add all the scenarios.

As we started stabilizing our test, support ticket creation rate dropped by 30%.

Thank you — Damien, for idea and Binti, for help.

Sprint performance 📊

When I joined the team, co-incidentally it was 2 days before the end of our sprint (which is 2 weeks long). There were couple of cards still in the ready lane. Ideally, by this time there shouldn’t be any ticket which has not even been picked up. Which clearly means it’ll be spilled over, as we can’t develop, test & release in just 2 days.

After understanding the context around the situation, we found out that there are a couple of bottlenecks like only our lead reviews all PRs & releases, he is also our scrum master. His schedules were already tight, so he had limited bandwidth for these.

So we decided that we’ll share the responsibilities. I also started reviewing the PRs, orchestrating releases. Beside, acting as a scrum master.

As we started sharing responsibilities, our sprint velocity improved by 31%.

Huge thanks to my lead — Kwanghock, for being so understanding & supportive.

Build time ⏳

One Fine Friday, we made a release (which in itself is not a good idea, but let’s keep that story for another day).

After office hours, when our operations people started processing, alerts started getting triggered for lags in the system. Soon it became a blocker and a highest priority support ticket was opened.
We figured out that we have released a query which involves searching non-indexed column. We quickly made a patch and pushed it.

The build agent took 15 minutes (which is against 10-Minute Build) to build our release. When the operation is blocked, each second counts. On top of this we forgot to refactor our unit test related to patch, so the build failed. Another 15 minutes for new build.

An automated build becomes a stress reliever at crunch time — XP

Digging deeper into the build logs I found out that the deletion of pod, which runs sonarqube job, is taking 9 minutes. Which is 60% of total build time.

Our infra team schedule is a bit packed right now, so I have volunteered to fix this.

As we fix our build pipeline, we should see a drop in build time by 60%.

Thanks to our Infra Dev — Ivan, for helping me to get started with this fix.

Hopefully you would have found these scenarios relatable. I encourage you to take initiative to fix yours. Even if it’s greek to us, let’s take a stab at it, with the mentality of sufficiency.

Be the change, you wish to see.

Feedback/thoughts https://forms.gle/KqAvwzj8tZmW5h5o6

--

--

Umair Mohammad

Software Engineer. Enthusiastic about tech, data, iot, software development methodologies and growing together.