When you hire someone to build software, you're not just buying code — you're buying a way of working. How a project is run determines whether you see steady progress or radio silence, whether you get the product you actually needed or the one written in a brief six months ago, and whether changes mid-way feel like collaboration or conflict.
This guide explains the main project management methodologies in plain language, weighs their trade-offs honestly, and then shows exactly how we run a project at Rephina — so you know what to expect before we start.
Why methodology matters more than it sounds
Most software projects don't fail because of bad code. They fail because of misalignment: the business needed one thing, the developer built another, and nobody noticed until it was expensive to fix. Or because requirements changed (as they always do) and the process couldn't absorb it. Or because the client had no visibility, assumed all was well, and got a nasty surprise at the end.
A good methodology is simply a system for keeping everyone aligned, surfacing problems early, and turning inevitable change into a managed process rather than a crisis. Let's look at the main options.
Waterfall: the traditional approach
Waterfall is the classic, linear model. You move through distinct phases in sequence: gather all the requirements, then design everything, then build everything, then test everything, then launch. Each phase finishes before the next begins — like water flowing down a series of steps.
Where it works: projects where the requirements are genuinely fixed and well understood up front, where change is unlikely, and where regulatory or contractual constraints demand heavy documentation.
Where it hurts: almost everywhere else. Its fatal flaw for most business software is that you don't see anything working until very late. If the requirements were slightly wrong — and after months, they usually are — you discover it only at the end, when changing course is most expensive. For a fast-moving SME, that's a serious risk.
Agile: a different philosophy
Agile isn't a single process; it's a mindset, captured in the Agile Manifesto back in 2001. It values:
- Working software over exhaustive documentation
- Customer collaboration over rigid contracts
- Responding to change over blindly following a plan
- Individuals and interactions over processes and tools
In practice, Agile means building software incrementally — in small, working slices — and constantly incorporating feedback. Instead of disappearing for six months and emerging with a finished product, an Agile team delivers usable pieces regularly and adjusts based on what you and your users actually think.
The core insight of Agile is humility: we accept up front that we won't get every requirement right on paper, so we build in a way that lets us learn and correct quickly.
Agile is an umbrella. Underneath it sit specific frameworks — the best known being Scrum and Kanban.
Scrum: structure for the work
Scrum is the most widely used Agile framework, and it's what most "Agile teams" actually practise. It organises work into a regular rhythm. The key ingredients:
Sprints
Work happens in fixed-length cycles called sprints, usually one to two weeks. Each sprint aims to produce a working, demonstrable increment of the product. This rhythm is the heartbeat of the project — predictable, repeating, and always ending in something you can see.
The backlog
All the desired work lives in a product backlog — a prioritised list of features and fixes. Before each sprint, the most important items are pulled into that sprint's plan. Because it's prioritised, the most valuable things get built first, which matters enormously when budgets are finite.
Sprint planning
At the start of each sprint, the team agrees what it will tackle. This keeps scope realistic and gives you a clear picture of what's coming next.
The daily stand-up
A short daily check-in (often 15 minutes) where the team confirms what's done, what's next, and what's blocking progress. It keeps things moving and surfaces obstacles fast.
The sprint review (demo)
At the end of each sprint, the team demonstrates the working software to you. This is the magic moment for a client: you see real progress every week or two, give feedback while it's cheap to act on, and steer the direction continuously.
The retrospective
The team briefly reflects on how the last sprint went and how to work better next time. Continuous improvement, baked in.
Roles
Scrum defines a Product Owner (represents the business and owns priorities), a Scrum Master (keeps the process healthy and clears blockers), and the development team. In a small engagement these roles are lightweight — but the principle of clear responsibility still applies.
Kanban: flow without fixed sprints
Kanban is another Agile approach, focused on visualising work and limiting how much is in progress at once. Work items move across a board — typically "To Do → In Progress → Done" — and the team deliberately caps how many things can be in flight, so nothing gets stuck and half-finished.
Where it shines: ongoing work with a steady stream of varied tasks — think maintenance, support, or a mature product receiving continuous small improvements. There are no fixed sprints; work simply flows as capacity frees up.
Many teams blend the two: Scrum's cadence for building a new product, Kanban's flow for supporting it afterwards.
So which is right for your project?
There's no universally "best" methodology — only the right fit for the situation:
- Building something new with evolving requirements? Agile, usually via Scrum. You'll see progress early and shape it as you go.
- A small, crystal-clear, fixed-scope task? A light, near-Waterfall flow can be perfectly efficient — no need for ceremony.
- Ongoing maintenance and support? Kanban-style flow handles a stream of varied work gracefully.
The wrong move is dogmatism — forcing every project through the same heavy process regardless of fit.
How we run projects at Rephina
We're Agile by default, Scrum-flavoured, and pragmatic about it. Here's what working with us actually looks like.
We start with discovery, not assumptions. Before any sprint, we invest time understanding your business, users and goals, and we document scope and success criteria. This isn't months of paperwork — it's enough clarity to build the right thing, with a roadmap you've agreed to.
We work in one-to-two-week sprints. Each sprint produces something you can see and click. No long silences.
We demo regularly. At the end of each cycle we show you the working software and gather your feedback. You're never waiting until the end to find out whether we're on track — you're steering the whole way.
We keep communication frequent and jargon-free. You get clear status updates (by email or WhatsApp, whatever suits you), a simple view of what's done and what's next, and immediate notice if anything threatens the timeline. Small business owners deserve plain language, not technical theatre.
We manage change honestly. Requirements evolve — that's normal and expected. When you want a change, we document it, explain its impact on time and cost transparently, and suggest alternatives that minimise disruption. Change becomes a managed conversation, never a hidden surprise on the final invoice.
We use simple, visual tracking. You can see the project board, understand task status, and view upcoming milestones. Transparency builds trust and prevents the misunderstandings that sink projects.
Our promise is simple: you should always know what we're working on, what's coming next, and roughly when it'll be done — without having to ask.
The payoff of doing it this way
Running projects the Agile way isn't just process for its own sake. It directly serves the things an SME cares about:
- Lower risk — because you see working software early and often, the gap between "what was built" and "what was needed" stays small.
- Better fit — continuous feedback means the final product reflects what you and your users actually want, not a guess frozen in a contract months ago.
- No nasty surprises — frequent demos and transparent change management mean you're never blindsided.
- Faster value — the most important features get built and delivered first, so you can start benefiting before the whole thing is finished.
Methodology is invisible when it works and painfully obvious when it doesn't. The way a project is run is every bit as important as the technology it's built on — and it's one of the clearest signals of whether you're working with a true partner or just a pair of hands.