Software Development Models: Waterfall, Agile and Kanban

So, what is the best working model for software product development? There is no single best model. Among software development models, the right choice depends on what your project has to fix (scope, time or cost) and what it can let move. Waterfall, Scrum, SAFe and Kanban answer that differently, and Microsoft's implementation guidance calls a hybrid of waterfall and agile popular and recommended for Dynamics 365 projects.

Software project delivery models have evolved dramatically over the past couple of decades (giving away my software age here), and this is a good thing (as can be the wisdom gained with human years). A short history lesson might well be appropriate now, as it may also be worth acknowledging what each model was designed to solve. This discussion is in two segments, sequential Waterfall and iterative Agile, followed by how the two are combined today, and how Zoosh Digital applies them.

Waterfall: the sequential model, and where it still fits

Waterfall runs a project's phases in sequence, with scope fixed up front. It suits requirements that will not move, and the UK government's Service Manual calls it “less effective for building and running services when technology changes quickly.”

Traditional software development models were typically sequential, the approach known as Waterfall. A Waterfall approach implied that the beginning, middle and end of a project are prescribed in advance. The respective scope and timelines are considered to be set in stone.

In practice, this means that significant time is spent on technical feasibility, requirements and feature specifications upfront and from this, a timeline is crafted to determine when a set of designed software would be ready for a final system and acceptance testing regime.

The main flaw with traditional Waterfall approaches is that they are rigid. To be effective, Waterfall delivery models require that all factors that influence a project have been captured or sufficiently covered by some contingent built into timelines and budgets. The scope must be known in advance and fixed. Changes that will be incorporated into a project's content must be coordinated in a controlled manner, typically with some flavour of change request procedure. The flaw is not that procedure but the assumption that scope will not move.

So, gone are the days when an Excel sheet containing a list of fixed, never changing, requirements could be sent to a software developer with a statement, “let me know when you will be ready with this”.

Fixed scope still has a place, and fixing the scope is not the same as building in one sequential pass. Zoosh Digital's explanation of why ERP implementations fix scope in writing before the project starts is blunt: “The go-live date should follow the defined scope. If the scope changes, the date changes.” In its guidance on how a partner handles scope changes during a project, a partner using written change requests, impact assessment and client sign-off “is managing the project professionally.”

Agile models: Scrum, SAFe and Kanban

Agile models, one family of software development methodologies, deliver software in short cycles and change the plan as the team learns, as the Manifesto for Agile Software Development set out in 2001. It values responding to change over following a plan, and adds: “while there is value in the items on the right, we value the items on the left more.”

Agile software development approaches orient around the collaborative effort of self-managing and cross-functional teams and their respective customers and users. In the Scrum Guide, Scrum Teams are “cross-functional, meaning the members have all the skills necessary to create value each Sprint”, and “self-managing, meaning they internally decide who does what, when, and how.” With this in mind, it's important to tailor the processes to your needs but keep the principles.

Scrum

The Scrum approach to software development allows for levels of structure to be introduced to focus a team on priority activities, while also allowing for sufficient flexibility to change direction periodically.

Work is broken into timeboxed windows called Sprints, and the Scrum Guide (November 2020) sets their length: “They are fixed length events of one month or less to create consistency.” Each Sprint produces an Increment, and “In order to provide value, the Increment must be usable.” Sprints are iterative, whereby you can have multiple Sprints during the lifecycle of a project. The content for each Sprint is selected from an ever-evolving and prioritised backlog of features. A product owner owns the backlog and is, in the Guide's terms, accountable for maximising the value of the product.

Scrum offers a level of predictability, as you know what to expect as output and when to expect it. Scrum also provides flexibility as the content for the following Sprint can change based on renewed priorities of content within the product backlog. Shorter Sprints are a team's choice, and on bespoke builds Zoosh Digital's guidance describes working software shown every two to four weeks.

SAFe

SAFe, the Scaled Agile Framework, runs many agile teams on one programme: Lean and Agile practice at scale, not a waterfall hybrid. Scaled Agile, Inc. presents SAFe 6 as helping organisations “become Lean Enterprise and achieve Business Agility”.

Kanban

Kanban is similar to Scrum in that it feeds off a backlog of content. The Kanban Guide (May 2025) defines it as a strategy for optimising the flow of value through a process.

Kanban imposes no timebox, so you might consider it less predictable. The Guide's answer: “Kanban system members must explicitly control the number of work items in a workflow from started to finished”, and they forecast with a service level expectation, “how long it should take a work item to flow from started to finished”.

When a designer or developer has capacity, they pull the highest-priority item. As you can imagine, there is much agility in this mode of working, but it does require that the product backlog owner be diligent in keeping priorities ever up to date. Otherwise, time can easily be wasted on a lesser priority task.

Agile vs waterfall: why the answer depends on what is fixed

Neither model wins in general. The right one depends on what your project has to fix: scope, time or cost. On Dynamics 365 projects a hybrid is common: Microsoft's implementation guide calls the hybrid of waterfall and agile “a popular and recommended methodology for Dynamics 365 projects”.

That hybrid “defines and designs the solution before starting the sprints, and uses sprints for refining, building, testing, and reviewing the solution.” Microsoft's guidance on the project approach warns of both extremes: no early blueprint means “designing and redesigning the solution from sprint to sprint”, and a strictly linear plan gives “little exposure to the working solution”. The contract side, which of time, cost and scope your contract lets move, matters as much.

Scrum vs Kanban: milestones or flow

Scrum vs Kanban comes down to which suits you, a presumed product backlog owner, best. If you like to work towards “milestones”, then Scrum may well suit you best. If, however, you prefer or need more flexibility, you'd likely lean towards Kanban, where flexibility comes from continuous flow. You need not pick one: the Kanban Guide says Kanban “can and should be used to augment” delivery techniques that share its theory, a mix sometimes called Scrumban.

Who owns the backlog when a partner does the building?

You should, whoever writes the code. The UK government's Contracting for Agile guidance note says that the buyer's intelligent client function (ICF) “will retain control of the project scope, including the movement of user stories up/down the backlog.” The GOV.UK Service Manual, written for government teams, adds: “Treat contractors and permanent staff as equal team members”, with a plan to pass knowledge on, “particularly important when you move from one phase to another, or if you change supplier.”

Zoosh Digital's published view of who does what comes from Microsoft Dynamics 365 Business Central implementations: “The partner does the technical work. The client provides the business knowledge, the decisions, and the internal ownership that make that work possible.” User acceptance testing (UAT) “requires the internal team's active participation”. If you do not own the backlog, you cannot steer the project.

How Zoosh Digital applies these models

Zoosh Digital is a Microsoft Dynamics 365 Business Central implementation and technology partner based in Ireland, helping mid-market organisations across the UK, Ireland and Europe with ERP and bespoke software. It works to The Zoosh Way: Foundation, Design, Build, Evolve, with “Co-creation at every step”, and one of its published principles is “We listen before we design”.

The model then follows what is fixed. On a Business Central implementation, Zoosh Digital's timeline guidance says “The first step in any engagement is the discovery and process mapping phase”, after which the scope is written and the go-live date follows it. On bespoke and custom software development, the build runs in short sprints, and Zoosh Digital's published guidance favours fixing a build price only once requirements are known.

Zoosh Digital describes itself as “senior-led rather than a large multinational”. Its limit is public: “if you want developers billed by the day and directed by your own project managers, you are describing a staffing arrangement and not an implementation partner”.

FAQ

Is agile better than waterfall?

Agile is not better than waterfall in general: the right model depends on which of scope, time and cost is fixed. The UK government's Service Manual calls a sequential waterfall approach less effective for building and running services when technology changes quickly, and Microsoft calls a hybrid of waterfall and agile popular and recommended for Dynamics 365 projects.

Can agile and waterfall be used together?

Agile and waterfall can be used together. Microsoft's implementation guide for Dynamics 365 describes a hybrid that designs the solution before the sprints start, then uses sprints to build, test and review it, and calls it popular and recommended for Dynamics 365 projects. SAFe is not that hybrid.

Is Scrum agile or waterfall?

Scrum is an agile framework, not a waterfall method. The Scrum Guide (November 2020) organises work into Sprints, fixed length events of one month or less, each producing a usable Increment. A self-managing, cross-functional Scrum Team selects each Sprint's content from a changing Product Backlog.

Is Kanban better than Scrum?

Kanban is not better than Scrum: they solve different pacing problems. Scrum paces work in Sprints of one month or less. Kanban, per the Kanban Guide (May 2025), paces work by flow, limits work in progress and forecasts with a service level expectation. The two can be combined.

How do you choose a software development methodology?

Choosing a software development methodology starts with what the project must fix. Known, stable requirements suit Waterfall. A product that users will shape suits Scrum. Continuous work with shifting priorities suits Kanban. For Dynamics 365 projects, Microsoft calls a hybrid of waterfall and agile popular and recommended, and the client should keep control of the backlog.

Closing thought

You choose a software development model once, but who owns the backlog is decided every week, in every priority call and change request, and that shapes your outcome more than the method's name. If you are weighing these models for a specific project, talk to Mervyn Graham and the Zoosh Digital team, including about whether a simpler model than the one you started with would do the job.

Referenced sources

• GOV.UK Service Manual. Agile and government services: an introduction. www.gov.uk/service-manual/agile-delivery/agile-government-services-introduction.
• Manifesto for Agile Software Development (2001). agilemanifesto.org.
• Ken Schwaber and Jeff Sutherland. The Scrum Guide (November 2020). scrumguides.org/scrum-guide.html.
• Scaled Agile, Inc. SAFe 6. framework.scaledagile.com.
• John Coleman, Daniel Vacanti and contributors. The Kanban Guide (May 2025). kanbanguides.org/english.
• Microsoft Learn. Choose a methodology for your Dynamics 365 project. learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/implementation-strategy-choose-methodology.
• Microsoft Learn. How to approach a Dynamics 365 implementation project. learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/project-governance-project-approach.
• Digital, Data and Technology Profession (GOV.UK). Contracting for Agile guidance note. www.gov.uk/government/publications/the-digital-data-and-technology-playbook/contracting-for-agile-guidance-note-html.
• GOV.UK Service Manual. Working with contractors or third parties. www.gov.uk/service-manual/the-team/working-contractors-third-parties.