Introduction to theAgile Model

Agile is something I kept seeing in job descriptions and LinkedIn posts but never really understood until I sat down and actually studied it properly. Before that I thought it was just one of those words people use to sound like they know what they’re talking about. Honestly it’s more practical than I expected, and once it clicks it’s hard to imagine doing software development any other way.

What I want to do here is explain it the way it actually makes sense to me — not copied from a textbook, just my own understanding of how and why it works.

The Basic Idea Behind Agile

So the whole point of Agile is that instead of trying to build a complete software product all at once, you split the work into smaller cycles. Each cycle is called a sprint and it lasts somewhere between 2 to 4 weeks. By the time a sprint finishes, you’re supposed to have a small but working piece of the product ready — not half-finished code, not just a design, something that actually runs.

The reason this matters is pretty simple when you think about it. Software projects take months or even years. A lot can change in that time — what the client wants, what the market looks like, what problems come up during development. If you’ve locked yourself into a detailed plan from day one, changing anything becomes painful. Agile says — don’t lock yourself in. Build a little, check if it’s right, then build a little more.

Why the Old Approach Kept Failing

The model that most teams used before Agile is called Waterfall. The name actually makes sense — the idea is that work flows downward through stages, one after another. First you collect all requirements. Then you design the system. Then developers build it. Then testers test it. Then it gets deployed.

On paper that seems fine. The problem is that testing comes at the very end. So if a developer made a wrong assumption about what a feature should do — back in the build stage — you don’t find out until months later when a tester finally looks at it. By then the fix isn’t small. It can affect a whole bunch of other things that were built on top of that wrong assumption.

There’s also the client problem. In Waterfall the client sees the finished product basically at the end. Imagine a client who asked for a blue website and you spent 6 months building it, then they say — oh I actually meant dark blue, more navy. That could have been caught in week 3. In Waterfall it gets caught at month 6.

These weren’t edge cases — this was happening constantly. Agile came out of developers being frustrated enough with this pattern that they wrote down a different set of values and published it. That document was the Agile Manifesto, written in 2001.

What the Agile Manifesto Actually Says

I think most people skip this part and go straight to sprints and standups. But the manifesto matters because it explains the thinking behind all of it.

There are four main values. Working software matters more than heavy documentation

— meaning don’t spend months writing specs if you could be building the actual thing. Collaborating with the customer matters more than arguing about contracts — keep the client involved, don’t just hand over a finished product and say “that’s what you asked for.” Being able to respond to change matters more than following the plan — if the plan stops making sense, update it. And people communicating directly matters more than relying on tools and processes to do it for them.

None of this sounds radical. But a surprising number of companies still operate in ways that contradict all four of these values. That’s why it still gets taught.

Walking Through a Sprint

Let me go through what actually happens during a sprint because I think this is where Agile gets real.

Building the Backlog First

Before any sprint can start, the team needs a list of everything the product might eventually need. This is called the Product Backlog. Each item on the list is written as a user story — basically a sentence from the user’s point of view. Something like: as someone using this app I want to be able to search by location so I don’t have to scroll through irrelevant results. The person responsible for keeping this list organized and prioritized is the Product Owner. They decide what’s most important and what can wait.

Planning Which Work Goes Into ThisS print

At the start of each sprint the team picks items from the top of the backlog and agrees on what they’ll try to finish. They estimate how long things will take and set a sprint goal. I found this step more important than I expected — teams that rush through planning often spend the sprint unsure about what they’re even trying to deliver.

The 15-Minute Daily Check-In

Every day there’s a short team meeting — meant to be 15 minutes, no longer. Each person says what they finished yesterday, what they’re working on today, and whether anything is blocking them. It’s not a formal status report. The goal is just to keep everyone on the same page and catch small problems before they grow. When teams treat it as a real conversation it’s useful. When they treat it as a ritual to get through it becomes a waste of everyone’s morning.

Testing Along side Development—Not After

This is the part that surprised me most when I first learned it. In Agile, testers don’t wait for all the development to finish. They test features as they get completed. So while one developer is finishing feature A, another might already be testing feature B that was done yesterday. Bugs get found fast, while the developer still remembers exactly what they wrote and why.

Compare that to Waterfall where a bug found in the testing phase might have been introduced 3 months ago by a developer who’s been working on something completely different since then. Tracking it down and fixing it is much harder.

Showing the Work—Sprint Review

At the end of the sprint the team demos what they built. The client or business stakeholders watch it live. They ask questions, give reactions, point out anything that doesn’t match what they expected. That feedback goes straight into planning the next sprint. This is the feedback loop that makes Agile work — every few weeks the client gets to course-correct before too much is built in the wrong direction.

Looking Inward—The Retrospective

After the review there’s one more meeting, just for the team. What went well this sprint? What didn’t? What’s one thing we want to do differently next time? It sounds small but teams that take this seriously genuinely improve over time. Teams that skip it or treat it as a checkbox just keep repeating the same problems.

The Three Roles You Need to Know

Agile teams in Scrum have three defined roles and it’s worth being specific because people mix them up.

The Product Owner is not a manager — they’re more like the team’s connection to the client and to the business. They own the backlog, they set priorities, and they make calls about what gets built and when. A Product Owner who is decisive and available makes a team’s life much easier. One who is constantly unavailable or keeps changing their mind is one of the fastest ways to derail an Agile project.

The Scrum Master is also not a manager. I want to be clear about that because the word Master makes it sound like authority. Their job is to support the team — run the ceremonies, remove anything blocking the team’s progress, and help the team get better at working together. They don’t assign work or evaluate performance.

The Development Team is everyone who actually builds and tests the product. In Agile this group is supposed to be self-organizing — they divide the work among themselves rather than being told what to do by a manager. That requires a level of trust that not every organisation is comfortable giving.

Scrum, Kanban, XP—What’sthe Difference

Agile is not itself a specific process. It’s a set of values. The actual processes that put those values into practice are called frameworks. Scrum is the most common one — it’s what most people picture when they hear Agile. Fixed sprints, defined roles, the

ceremonies I described above. It works well for product development with a relatively stable team.

Kanban is different. There are no sprints — work just flows continuously through a board with columns like To Do, In Progress, Done. The key rule is that you limit how many things can be in progress at once. This stops the team from starting ten things and finishing nothing. It works well for teams handling ongoing support work where you can’t really predict what’s coming.

Extreme Programming or XP focuses on the technical side more than the other two. Pair programming — two people writing code together on one computer — is one of its practices. Test-driven development — writing the test before writing the code it will test

— is another. These take discipline but produce noticeably better code quality over time.

Honest Assessment— What Agile Does and Doesn’t Do Well

I think the most useful thing I can say here is that Agile is genuinely good at some things and genuinely bad at others, and pretending otherwise doesn’t help anyone.

It’s good at keeping clients involved so that surprises at the end are less likely. It’s good at catching bugs early when they’re still cheap to fix. It’s good at helping teams adapt when requirements shift. And it builds in a regular habit of improvement through retrospectives which is underrated.

But it relies heavily on the client actually being available and engaged throughout. If the Product Owner is unreachable or constantly changing direction, the team suffers. It also makes it genuinely difficult to give firm cost and timeline estimates upfront, which is uncomfortable for clients who need a fixed-price contract. And if the team isn’t disciplined about keeping sprint scope realistic, the project can drift without a clear finishing point.

None of these are reasons to avoid Agile. They’re just things to be aware of going in.

What Changes for Testers in an Agile Team

This is particularly relevant to me since I’m preparing for a role in software testing. Agile changes the job quite a bit compared to what testing looks like in traditional models.

The biggest change is that testing isn’t a separate phase at the end. It runs throughout the sprint. From the first day of a sprint, testers are sitting in planning meetings, reading user stories, thinking about edge cases before the developer has written a single line of code. Early involvement like this often prevents bugs from being introduced in the first place — which is obviously better than finding and fixing them later.

Regression testing also becomes a serious ongoing concern. Every sprint adds new features, and those features can break things that were already working. Testing a growing product manually after every sprint quickly becomes unsustainable, which is why automation is so central to Agile testing work.

Selenium is the tool most commonly used for browser-based test automation. TestNG helps organize and run test suites efficiently. Cucumber supports something called Behaviour-Driven Development where test scenarios are written in plain English — ‘Given the user is on the login page, when they enter correct credentials, then they should see the dashboard.’ The value of that is that non-technical people can read and even contribute to writing those tests. It closes the gap between what the client describes and what actually gets tested.

A Practical Example — Thinking Through a FoodApp

When I was trying to make this concrete in my head I kept coming back to the example of a food delivery app. It’s something most people have used so it’s easy to picture.

Say a team is building something like Swiggy from scratch. A Waterfall approach would mean spending the first few months gathering every requirement — user accounts, restaurant listings, menus, searching, ordering, payment, delivery tracking, ratings, offers, notifications. Then designing all of it. Then building all of it. Then testing everything. Then releasing. That process alone could take over a year, and the market doesn’t wait.

An Agile team would think about it completely differently. Sprint 1 — just get user registration and login working. Sprint 2 — add restaurant browsing. By the end of sprint 2 there’s something real that actual users can open and click around in. Maybe they find that the search bar placement is confusing, or that the cuisine filter nobody asked for is actually what everyone uses first. You learn that in sprint 2 and adjust sprint 3 accordingly.

Sprint 3 adds ordering. Sprint 4 adds payment. Each sprint is shaped by what the previous one taught you. By the time the full product ships it reflects real behaviour, not just assumptions made in a meeting 12 months earlier. That’s a meaningfully different kind of product.

To Wrap Up

What I took from studying Agile is that it’s not really about sprints and standups — those are just mechanics. The actual idea is simpler. Software development is unpredictable so stop pretending it isn’t. Build something real, show it to someone, find out if it’s right, then build the next thing. Repeat until done.

The teams that get the most out of it are the ones who genuinely use the ceremonies as tools — not as rituals — and who are honest in their retrospectives rather than polite.

The teams that struggle with it are usually either going through the motions without the mindset, or working in organisations that say they want Agile but still expect waterfall- style upfront commitments.

For testing specifically — Agile makes the job more demanding in some ways but also more interesting. You’re not waiting at the end of a pipeline. You’re involved from the start, which means your input actually shapes what gets built rather than just verifying it after the fact.