For three years we worked in a waterfall model. It worked, but as the number of projects grew and demands for faster delivery increased, we hit its limits. Clients don’t want to wait 6 months for a first result.
Why not waterfall¶
Waterfall works for projects with clearly defined requirements that don’t change. But in practice that’s rare. Clients change their minds after the first prototype — in waterfall that means change requests and delays.
Scrum basics¶
Two-week sprints. Sprint planning, daily standup (15 minutes), sprint review with the client, retrospective. Product backlog prioritized by the product owner. Scrum master rotates.
Resistance to change¶
Cultural barrier: Why a meeting every day? Why can’t I work in peace for two weeks? It took three sprints for the team to adapt. And another three before it really started working.
What works, what doesn’t¶
Works: short iterations, retrospectives, user stories. Doesn’t work: pure Scrum with a fixed-price contract. Compromise: Scrum within the team, agreed milestones for the client.
Tools¶
JIRA with the Agile plugin for backlog and sprint board. Confluence for documentation. The physical board was abandoned due to remote developers.
Lessons after one year¶
Scrum is not a silver bullet, but for most projects it’s better than waterfall. Discipline, client engagement and patience are key.
Need help with implementation?
Our experts can help with design, implementation, and operations. From architecture to production.
Contact us