'We've been paying for 6 months on a project that should have taken 3. Nobody showed us a single screen until month 5.' — This statement is repeated by 70% of SMEs that hire software development without agile methodology.
Agile methodologies were born to solve exactly this problem: delivering value incrementally, with full visibility and the ability to adapt. In this guide we explain how Scrum and Kanban work, when to use each one, and how to verify your provider actually applies them. If you need personalised guidance, our technology consulting service can help you choose the right approach for your project.
Why the Waterfall Model Ruins Projects
The waterfall model is still the most common way to manage software projects in Spanish SMEs. The problem is that it assumes you can define all requirements upfront and that they won't change. In reality, that almost never happens.
- You see no results until the end: the provider works for months without showing you anything functional, and when they do, it's too late to correct conceptual errors.
- Expensive changes: any modification mid-project means redesigning earlier phases, multiplying costs and timelines.
- Risk concentrated at delivery: if the final product doesn't match what you needed, you've lost months and budget with no way to course-correct.
Scrum for SMEs: Deliveries That Work
Scrum divides the project into short cycles called sprints (typically 2 weeks). At the end of each sprint, the team delivers a functional product increment that you can test, validate and prioritise.
Product Owner
Represents the business. Defines what gets built and in what order based on business value. In an SME, this is usually the manager or the head of the department that will use the software.
Scrum Master
Facilitates the process. Removes blockers, ensures the team follows Scrum rules and protects the team from external interruptions.
Development Team
The engineers who design, code and test. They are self-organising: they decide how to do the work, not just what to do.
The sprint process includes: planning (what will be done), dailies (15-minute daily meetings to synchronise), review (demo of the increment to the client) and retrospective (what to improve in the next sprint). This cycle guarantees constant visibility and the ability to correct course early.
Kanban: Continuous Flow Without Sprints
Kanban doesn't work with fixed sprints. Instead, it visualises work on a board with columns (To Do, In Progress, Done) and limits the number of simultaneous tasks (WIP limits). It's ideal when the workflow is continuous and priorities change frequently.
- Ongoing maintenance and support of existing applications.
- Teams managing requests from multiple internal departments.
- Projects where priorities change weekly based on business needs.
- Situations where you can't commit to deliveries every 2 weeks because the workload is unpredictable.
Scrum vs Kanban vs Waterfall
This table summarises the key differences between the three methodologies so you can evaluate which best fits your project.
| Aspect | Scrum | Kanban | Waterfall |
|---|---|---|---|
| Cycles | 1-4 week sprints | Continuous flow | Sequential phases |
| Planning | Per sprint (short-term) | On demand | Complete upfront |
| Visibility | Every 2-4 weeks (demo) | Real-time (board) | Only at project end |
| Ideal for | New projects with definable scope | Support, maintenance, operations | 100% fixed and known requirements |
| Risk | Low (corrections each sprint) | Low (continuous adjustment) | High (errors discovered late) |
| Roles | PO, Scrum Master, Dev Team | No mandatory roles | Centralised Project Manager |
How to Know if Your Provider Truly Uses Agile
Many providers claim to use agile but in practice still work in waterfall under a different name. These five questions will help you distinguish real agile from marketing.
- Can I see the project board in real time? (If the answer is no, it's not agile.)
- How often will you deliver something functional I can test? (The correct answer is every 1-4 weeks.)
- Can I attend sprint reviews or demos? (If they don't invite you, there's no transparency.)
- What happens if I want to change a priority mid-sprint? (They should explain how they manage changes without chaos.)
- How do you measure team velocity? (If they don't measure, they can't predict timelines or improve.)
Implementation Mistakes
Even when agile is adopted with good intentions, these mistakes are common and can negate its benefits.
- Scrum without a real Product Owner: nobody prioritises the backlog with business criteria and the team builds features nobody uses.
- Sprints without client demos: the team works in cycles but the client sees nothing until the end. It's waterfall in disguise.
- Kanban without WIP limits: the board exists but everything is 'in progress' at the same time. Without limits, there's no flow.
- Retrospectives that generate no changes: the team identifies problems but nobody solves them. Continuous improvement dies in the meeting.
Frequently Asked Questions: Agile Methodologies for SMEs
Scrum or Kanban for my project?
Scrum is ideal for new projects with scope you can define in phases: developing an app, a custom ERP or a SaaS platform. Kanban works better for ongoing maintenance, technical support and teams managing requests from multiple sources with changing priorities.
How long does a sprint last?
Between 1 and 4 weeks. The most common for SMEs is 2 weeks: enough to deliver something functional without losing agility. Shorter sprints (1 week) work for very mature teams; longer ones (4 weeks) only if the work requires extensive validation cycles.
Do I need a Scrum Master?
Yes, you need someone to facilitate the process and remove blockers. In an SME it doesn't have to be a full-time role: it can be a member of the provider's team who takes on that responsibility. What matters is that someone protects the process and ensures impediments are resolved quickly.
How do I know if my provider really uses agile?
Ask to see the project board (Jira, Linear, Trello). Attend sprint reviews and verify they deliver functional increments every 2-4 weeks. If you only receive PDF reports without working software, it's not agile, regardless of what they say.
Conclusion
The difference between a project that fails and one that works is rarely the technology: it's the methodology. Scrum and Kanban are not fads or abstract frameworks; they are proven tools that enable delivering software predictably, with full visibility and the ability to adapt. The key for an SME is choosing the right methodology based on the project type, demanding real transparency from the provider and actively participating in the process. A good technology partner doesn't just write code: they invite you to see how they do it.
