27 Apr 2025 3 min read

How Agile Principles Helped Me Choose the Right Agile Process

This is a story about how I applied Agile principles to decide which Agile process was best for our team. It sounds a bit odd, I know — but believe me, you’ll soon understand what I mean.

Context

Just to give you some background: initially, we were having a great time with standard Scrum-based Agile processes. That was when we had lots of feature requests coming from the product side.

It was easier to have a common Sprint goal, our commitment to Story Points was solid, and our velocity was consistent and even growing slowly over time. All of this showed that we were maturing as a team, improving steadily.

But all the good stuff started fading when most of our tasks and stories became technical in nature. At some point, we hit a saturation point for new features and mostly worked on technical improvements instead.

During this time:

We couldn’t find a common Sprint goal anymore.
Our commitment to Story Points started going haywire.

Action

Everyone could feel the issues, but — like me — no one really took the initiative to fix them at first.
After a while, I said to myself: "Enough. I have to raise this concern."

So, I brought it up during one of our Sprint Retrospective meetings.
(If you’re not familiar with Agile rituals like Sprint Planning, Retrospective, or Daily Standups, I highly recommend you check out my earlier post)

Raising the concern was the first step in acknowledging the problem. As I had hoped, everyone agreed that it was something we needed to address urgently.

I shared my analysis of the root causes:

There was too much variety in the technical issues and bug fixes we were tackling. Everything was heading in different directions, making it almost impossible to define a single Sprint goal.
It also impacted our QA (Quality Assurance) team, since the affected areas spanned across different functional modules.

At the same time, I proposed a simple idea:
We were running two-week Sprints — what if we reduced it to one week?
The hope was that shortening the cycle would naturally reduce the scope of each Sprint and help us stay focused.

Action (Continued)

Trying out the one-week Sprint did help a bit, but it wasn't enough.
The main problem — the variety of technical tasks — still persisted.

After a few weeks, it was clear that the impact wasn’t significant. It was time for a bigger change.

I did a bit of research into different methodologies, and Kanban caught my attention.
(I know, I don’t have an article about Kanban yet — sounds like an action item for me! 😄 But for now, you can understand Kanban as a stream of pre-prioritized tickets that developers pull when they finish or get blocked on a task.)

The beauty of Kanban:

It doesn’t force you to chase a common Sprint goal.
It allows continuous delivery without being tied to a strict timeline.

We gave it a try, and after a few weeks, we were confident:
Kanban was the right fit for our new working style. 🎯

✅ First root cause: solved.

But there was still some frustration within the QA team around testing timelines.

Digging deeper, we discovered:

QA had low automated test coverage.
They were spending too much time on manual testing.
And because they were so busy manually testing, they didn’t have time to build automation!

It was the classic chicken-and-egg situation.

My suggestion:

Developers should own the testing for purely technical tickets.
QA should focus on functional validation and building automation.

We updated our process:

Tickets requiring QA testing were labeled clearly.
Technical-only tickets were owned end-to-end by developers.

Slowly, the QA team found the breathing room to ramp up automated testing, leading to much better test coverage — and finally, confidence in catching regressions automatically. 🙌

Learnings

🧠 Address problems early:
The sooner you spot an issue, the faster you can solve it. We delayed a bit, and it cost us valuable time.

🧠 Be open to experimentation:
If our team hadn’t been open to trying different approaches, we wouldn’t have found a better alternative that fit our needs.

🧠 Developers must own technical ticket delivery:
Technical improvements should be tested and validated by developers. We were guilty of pushing these onto QA unnecessarily, and it created an avoidable burden.

Let me know your thoughts — and if you have any topic suggestions, feel free to send them my way! 🚀