What Even Is Agile, Anyway?
For teams that adopted agile but can't seem to make it work
In this post, I want to talk about the agile process — one of the many software development methodologies out there. Many organizations have already adopted agile, and the company I work at is no exception.
A lot of teams focus on the surface-level rituals: assigning story points to issues, running 1-2 week sprints, holding daily scrum meetings. My workplace was doing all of that too, but everyone kept asking “what does it actually mean to work in an agile way?” without ever getting a proper answer.
We started without understanding the essence of agile — just “I tried this a few times and it worked great!” or “another company does this and they improved!” Naturally, things didn’t go smoothly. Estimations were consistently off, sprints kept falling apart, and team morale suffered. So my company, Soomgo, invested a significant amount of money to bring in an agile coach for about a month of training.
In this post, I’d like to share what I learned from that experience, along with what I noticed after trying various approaches in practice.
Why Use Agile?
Since so many organizations already use agile, I’ll assume most of you have a general idea of what it is.
Agile means “nimble” — it’s a development methodology born from the intent to find a balance between having no plan at all and having an overly rigid plan.
The traditional approach is best represented by the waterfall model. Its defining characteristic is that it charges straight ahead with a remarkably optimistic mindset.
Traditional methodologies like waterfall generally follow this structure:
Planning > Design > Development > Testing > Deployment > Maintenance
Looks familiar, right? It’s a process most of us have been through, whether we realized it or not. You set a deadline, and every team member finishes their part and passes it along. If everything goes smoothly, it’s a happy ending for everyone. But reality has other plans.
The "client with unreasonable demands" — a universal experience
In the real world, clients might see a prototype and request changes. Even for in-house products, you might ship something after months of hard work only to find that user reception is nothing like you expected.
In these situations, the waterfall model forces too much risk onto the team. All that effort over one or two months can evaporate in an instant. And then there’s this scenario:
Planning > Design > Development (Wait, this is actually impossible given the current situation…?)
If a developer was part of the planning meetings, this can sometimes be caught early. Otherwise, you have to go back to the planners, explain why it’s not feasible, and restart the planning and design process from scratch. At best, it wastes time. At worst, it creates friction between team members and damages morale — not a good experience. (I take my team members’ emotional well-being very seriously.)
So let’s look at what agile is — the methodology designed to overcome these shortcomings of traditional approaches.
The Agile Manifesto
The agile development methodology begins with the Agile Manifesto, published in 2001.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the left, we value the items on the right more.
Manifesto for Agile Software Development agilemanifesto.org
From this manifesto, we can understand what agile values. Put more casually, it goes something like this:
We’re a team, so let’s communicate instead of working in silos!
Let’s not waste time on unnecessary documentation — build something that actually works first!
Let’s create a product that customers actually find valuable!
Plans always change, so let’s work flexibly enough to adapt!
Agile is highly idealistic. It’s about becoming an organization that moves fluidly with the singular goal of building products for the customer.
The Twelve Principles Behind the Agile Manifesto
Beyond the manifesto itself, agile establishes 12 principles to guide teams.
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Principles behind the Agile Manifesto agilemanifesto.org
The things we typically associate with agile are built on these 12 principles.
For example, sprints are based on principle #3, and the retrospective held at the end of each sprint is based on principle #12.
Agile also favors small task force teams over large ones, which comes from principle #5. The reasoning is simple: smaller teams can move more organically than large ones.
These 12 principles serve as a guideline for how to produce and deliver products to customers more nimbly.
The Core Elements of Agile
[Source] https://brainhub.eu/blog/differences-lean-agile-scrum/
Agile has several components based on the 12 principles. In this post, I’ll focus on the ones I consider most important: User Story, Backlog, Estimation, and Retrospective. Let’s take a quick look at each.
User Story
Agile is built around user stories. Stories are crucial, and they must be thoroughly user-centric. When we typically create stories or issues, they tend to look something like this:
- SD-1234 Revamp the request form page
- SD-1235 Convert the webview-based profile page to native
- SD-1236 Design DB schema and create API endpoints for social login
- SD-1237 Add multi-photo sending feature to user chat
When I received agile coaching, this was the very first thing the coach pointed out. The coach recommended that stories include three elements wherever possible: Who, What, and Why.
Stories written this way explain, through the title alone, why the team needs to address them. So the stories above should be rewritten like this:
- SD-1234 A customer can see all the information they need at a glance to easily submit a request.
- SD-1235 A customer can use the profile page as a native view instead of a webview for a more natural UX.
- SD-1236 A client developer can use the relevant API endpoints to build the social login feature.
- SD-1237 A customer can use a multi-select feature to easily send multiple photos in a chat.
User stories written this way can be understood by any team member — even someone completely unrelated to the story — without additional explanation.
And the user (Who) doesn’t always have to be the customer. In SD-1236, the user is the client developer. In cases like this, you still fill in all the information: the client developer (Who) can use the relevant API endpoints (What) to build the social login feature (Why). Team members are both producers and each other’s internal customers.
Product Backlog
The product backlog consists of multiple user stories that need to be addressed. These stories are sorted by priority as defined by the PO (Product Owner), and prioritization authority rests solely with the PO. A fundamental prerequisite of agile is that team members trust the PO’s decisions.
That doesn’t mean blindly following orders — you can freely discuss and voice opinions, but the final call is the PO’s.
The backlog will keep accumulating stories if left unattended, so the PO needs to periodically review and prune it — deciding which stories are still relevant and which aren’t. Without this maintenance, it takes increasingly longer to sort through and evaluate the backlog.
Estimation
Estimation is the process where team members who will actually work on the stories assess how large each story is by assigning story points.
A common approach is to use absolute values — if an issue takes 1 hour, it gets 1 story point. My team initially did this too. We decided that 4 hours was a realistic amount of focused work per day, so a task taking about a day was estimated at 4 points.
The problem was that these estimates were almost always wrong. Unless you’re some kind of savant who can predict exactly when your work will be done, unexpected bugs, surprise meetings, or sick days throw everything off. It happened more often than you’d think, and each time, the sprint would blow up.
So we switched to relative story points. Here’s how it works. You pick a past story as a reference point and have the team estimate it based on their memory of that experience.
SD-1234 A customer can see all the information they need at a glance to easily submit a request.
Alice: This one wasn’t that much work, I think. I’d say 3.
Bob: I was doing overtime every day designing this. I’d say 5.
Charlie: I have a crush on Bob, so I’ll say 5 too.
Once the team converges on a rough consensus — “redesigning the request form page was about a 5” — you use that as a baseline to relatively measure other stories. You can use T-shirt sizes like XS, SM, M, L, XL, or natural numbers like 1, 2, 3, 4. Since you’re measuring relative size, any abstract scale works.
For reference, my team uses the Fibonacci sequence: 1, 2, 3, 5, 8...
Measuring relative size might feel strange at first, but from my experience, it’s more accurate than estimating in hours. The caveat is that you first need to know roughly how many story points your team can handle in a sprint.
This is figured out by simply running a few sprints. If you completed 40 points in the first sprint and 20 in the second, load about 30 points into the next sprint.
Even though the second sprint’s completion rate dropped 50% compared to the first, don’t worry!
Unfinished issues from the second sprint carry over to the third, so the third sprint’s completion rate will be higher than expected. Average it out over a few sprints, and you’ll get a reliable baseline for your team’s velocity.
A bad sprint is likely followed by an overachieving one!
And here’s the important part: the sprint deadline is not a hard deadline. If a deployment was late, analyze why and make sure it doesn’t happen again. Don’t stress too much. Just don’t make the same mistake twice.
Retrospective
The retrospective is held at the end of each sprint, and I consider it the most important element of agile.
A retrospective is a lightweight meeting where the team discusses how to improve. It should never feel heavy or intimidating!
At my workplace, we sometimes hold retrospectives at a café near the office over coffee. One method is to draw a timeline, have team members write warm moments and cold moments on sticky notes, place them on the timeline, and vote on topics to discuss. Another is to simply have everyone bring a topic and discuss freely.
Through the retrospective, the team decides on action items for the next sprint and assigns an owner to each one. Without a designated owner, action items tend to fizzle out.
The assigned team member periodically reminds others and takes responsibility for completing the action item within the sprint.
So Is Agile Good?
Personally, I prefer agile — handling small stories and deploying within 1-2 weeks — over the waterfall model with its looming deadlines. Short development-to-deployment cycles mean faster user feedback, and the satisfaction of shipping frequently is genuinely motivating. But agile isn’t a silver bullet that works in every situation. There are awkward gray areas.
“This Isn’t Agile!”
I’ve heard this line quite a few times during daily scrums at work. The situation typically goes like this:
Something needs to be done. → The issue turns out to be bigger than expected. → There are heavy dependencies between features, so deploying separately is difficult. → Let’s just do it all at once and deploy!
Then someone chimes in:
Hmm, but… that doesn’t seem very agile, does it?
And suddenly everyone’s head is spinning. “How do we handle this in an agile way?” Someone asks “so what would the agile approach be?” but nobody has an answer — because the issue simply can’t be broken down into smaller pieces.
But this isn’t what agile is about. Agile isn’t a rigid set of rules and regulations.
Sure, there’s the Agile Manifesto and the 12 principles, but those are just guidelines. Every team is different — the idea that a single method works perfectly for every team in the world is absurd.
I believe in following agile’s basic guidelines while flexibly adapting them to fit each team. You don’t have to follow the manifesto or the principles to the letter. If your team comes up with some creative approach that works for them, that’s perfectly fine. We’re all just trying to work well together — there’s no reason to create rigid rules for the sake of it. Just get the work done.
Don’t Get Too Hung Up on Agile
When I first heard the Agile Manifesto, I’ll be honest — it reminded me of communism.
When Marx first proposed Marxism and wrote Das Kapital, the prevailing sentiment among workers was that communism was the perfect system, that it would keep evolving while capitalism would eventually collapse on its own. But communism in practice hit the wall of reality, mutating into Stalinism, Maoism, and other variants that mostly ended in dictatorship.
What started as “let’s all prosper together” became “let’s all be poor together” once it met the real world.
Similarly, agile in practice doesn’t always run as smoothly as the theory suggests. The situation I described above is one of many awkward scenarios. What do you do when an issue can’t be broken down and won’t fit within a single sprint?
The Agile Manifesto says all the right things, but obsessing over it can turn your organization into one that creates work for the sake of work.
Consider the capitalism we enjoy today. If it had stayed as Adam Smith originally envisioned — “leave the market alone and it’ll sort itself out” — it probably would have collapsed. But by incorporating good ideas from socialism through policies like the New Deal — nationalization programs, welfare policies — capitalism evolved and survived. Nothing is absolutely perfect.
Likewise, whether it’s agile, waterfall, kanban, or whatever else — I think all that matters is working efficiently. So I took the Agile Manifesto in one ear and let it out the other. Mix and match whatever looks good, and if it works for your team, that’s all that counts. The manifesto says such obvious things that it didn’t feel worth memorizing.
Wrapping Up
What I took away from the agile coaching was the ironic realization that “there’s no right answer in agile” — and simultaneously, “wait, so does that mean as long as you can ship products nimbly, the manifesto and everything else doesn’t actually matter?”
I still believe that agile is simply about delivering products to customers nimbly — whether your sprints are one week or two, however you do estimation, whatever your method. It doesn’t matter.
That said, if your team is looking to adopt agile, I think it’s worth doing it properly, which is why I’m sharing what I learned from our coaching experience. Having the team come together, try different approaches, reflect on what worked through retrospectives, and discuss how to improve — that’s an experience that’s genuinely hard to come by. It’s actually really fun, I promise.
Agile, done right, requires a surprising amount of study. There’s a lot to learn, and you need the ability to adapt and evaluate these concepts for your specific team. But from what I’ve experienced firsthand and heard from developers at other organizations, many teams that claim to practice agile are simply running sprints, holding daily scrum meetings, and using JIRA — and calling that agile.
Without knowing how many story points your team can realistically handle per sprint, or checking whether your external and internal customers are actually satisfied — agile without this kind of continuous inspection is nothing more than repeating 1-2 week deadlines. I’ve been there, and trust me, it’s miserable. The constant pressure of deadlines every single week… ugh.
I hope that as you develop an interest in agile, you’ll also bring a passion for collaboration — and that you can have fun while working with your team.
That wraps up this post on what agile even is.