Agile Methodology in Action

Hey folks

I’m a software engineer passionate about building efficient, user-friendly systems. I love exploring system design, scaling applications, and experimenting with side projects that solve real-world problems. Curious by nature, I’m starting to use Hashnode as a place to share my journey, connect with developers, and keep learning along the way.

And what better way to start than by writing about something I practice almost every day — Agile methodology in action.

Understanding the Business Need

Whenever a new feature comes up, the first step is not coding — it’s understanding the business need.

We think like end users:

• Is this feature useful?

• How will it solve the actual problem?

• Is it aligned with what the business is trying to achieve?

This phase is all about asking the right questions, removing ambiguity, and getting clarity before we move to technical decisions.

Documentation & Queries

Once the need is clear, we start with technical documentation.

• Queries are fixed, optimized, and benchmarked on the pre-prod environment.

• Pre-ARB (Architecture Review Board) discussions help us finalize API signatures and other important decisions.

This step saves us from last-minute surprises and ensures performance is considered from day one.

Development Workflow

With clarity and documentation in place, we move to development.

• Using tools like Atlassian MCP (for JIRA context) and Confluence (for API + tech documentation) keeps everyone aligned.

• We define API signatures, keep track of stories, and make sure we’re following SDLC practices.

• Coding standards are followed to ensure scalability and maintainability.

It’s less about writing code fast, and more about writing code that will stand the test of time.

Testing & Reviews

Before the code reaches QA, there are multiple checkpoints:

• Integration testing to validate the flow.

• Peer reviews & code reviews to ensure quality and correctness.

• ARB reviews to make sure everything aligns with architecture guidelines.

• Code must be merged into a protected branch before being handed off to QA.

This way, QA gets something stable and reliable to test, instead of firefighting basic issues.

Wrapping Up

That’s a quick peek into how we usually approach building a feature — structured yet flexible, with a balance between business and technical needs.

From here on, I’ll be documenting not just processes like these but also side projects, experiments, and learnings. Excited to stay consistent and connect with fellow devs here 🚀