- ✓No development methodology is universally optimal: the best choice depends on the stability of requirements, the size and experience of the team, the tolerance for risk, the pace of delivery expected and the organisational culture.
- ✓Scrum is the most widely used Agile framework, organising work into time-boxed sprints with defined ceremonies (sprint planning, daily stand-up, sprint review and retrospective) and clear roles (product owner, scrum master and development team).
- ✓Kanban visualises work in progress and limits the number of tasks in each stage of the workflow, helping teams identify bottlenecks and maintain a smooth, sustainable flow of completed work.
- ✓DevOps extends Agile principles to the entire software delivery lifecycle, breaking down the traditional barrier between development and operations teams to enable faster and more reliable deployment of software changes.
- ✓Evaluating development methodologies critically requires looking beyond the promises in their marketing material to examine the evidence from real implementations, including both the successes and the common failure modes associated with each approach.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Hello and welcome back to The Study Podcast. Today we're evaluating application development methodologies and thinking critically about which approach fits which context. Sam, we touched on this in the SDLC unit at Level 4, but at Level 5 we're evaluating more deeply.
Sam: That's right. At Level 4 we described the methodologies. At Level 5 we're expected to evaluate them critically: understanding not just what each methodology is but when it works well, when it doesn't, and how to make a reasoned recommendation in a specific context.
Alex: Let's take Scrum first. What are its genuine strengths and its genuine limitations?
Sam: Scrum's genuine strengths are its rhythm and its visibility. The sprint structure creates a regular heartbeat of planning, execution and review that keeps teams focused and creates predictable opportunities for stakeholders to see progress. The daily standup, when run well, creates shared awareness and surfaces blockers quickly. The retrospective creates a structured opportunity for continuous process improvement. Its limitations include the risk of the sprint becoming a mini-Waterfall within a larger project if the planning is done rigidly, the overhead of Scrum ceremonies in small teams where the formality may not be worth it, and the tendency for some teams to treat Scrum as a rigid set of rules rather than a framework to be adapted.
Alex: What about Kanban?
Sam: Kanban is simpler and more flexible than Scrum. Its core mechanism is the visualisation of work on a Kanban board and the limitation of work in progress at each stage of the flow. It's excellent at revealing and addressing bottlenecks: when you can see that ten tasks are waiting for code review while the development stage has only two, the implication is clear. It works well for operations and support teams where work arrives continuously and unpredictably rather than in planned increments. Its limitation is that without the sprint boundary forcing regular review and prioritisation, backlogs can grow indefinitely and strategic focus can be lost.
Alex: And DevOps as a methodology?
Sam: DevOps is more of a culture and a set of practices than a methodology in the same sense as Scrum or Kanban. Its core contribution is breaking down the historical barrier between development, which was incentivised to make changes, and operations, which was incentivised to maintain stability. The combination of shared responsibility, automation of deployment and testing, and the ability to deploy small changes frequently and safely, is genuinely transformative for organisations that can make the cultural shift. The barriers to adoption are significant: it requires substantial investment in automation tooling, a culture of shared accountability and in many organisations a reorganisation of team structures.
Alex: How should a learner approach an assessment question asking them to evaluate and recommend a methodology?
Sam: Start by understanding the context: what kind of project, what kind of team, what kind of organisation? Then evaluate each methodology against the specific context rather than in the abstract. Don't just list the pros and cons of each: apply them to the scenario and explain why the advantages matter in this case and whether the limitations can be managed. And make a clear recommendation with a reasoned justification: hedging everything is less convincing than taking a position and defending it well.
Alex: Exactly the critical thinking Level 5 requires. Thanks, Sam.