Edele Gormley

There's more to Agile than Scrum and Kanban: 3 alternatives

< Back to overview

Most people have heard of Scrum and Kanban, but what about the other Agile approaches?

When I was first learning about the various approaches to software development, Scrum wasn’t as prevalent as it is today—it was just one approach in a crowd of many. So what’s happened to the others? Why has Scrum surpassed them in popularity? Are they really not relevant anymore?

Let’s look at three such methodologies, starting with the first I actually encountered in my working career, DSDM.

Dynamic Systems Development Method (DSDM)

DSDM is a framework that takes a “grown-up” approach to Agile, as its focus is on bringing agility to corporate, project-based environments. It was originally published in 1995 by the DSDM Consortium (now known as the Agile Business Consortium). DSDM promotes doing just “enough design up front” (EDUF), in what it calls a Foundations phase, and uses iterations to develop further—in contrast to Waterfall’s comprehensive planning phase.


  • Focus on the business need - every decision should be viewed in terms of the overriding project goal
  • Deliver on time - late delivery can undermine the rationale for a project, especially where market opportunities or legal deadlines are involved
  • Collaborate and Cooperate with each other - encourages increased understanding, greater speed and shared ownership
  • Always focus on quality, never compromise on quality
  • Build solution incrementally - encourages stakeholder confidence, allowing feedback to be used in subsequent timeboxes
  • Develop solution in iterations - encourages timely feedback and the ability to embrace inevitable changes
  • Communicate continuously to get feedback
  • Establish control through plans - the plan is clearly aligned with agreed business objectives


  • Pre-project phase - ensures only the right projects are started and based on a clearly defined objective that is aligned to the overall business goals
  • Feasibility phase - to establish technical feasibility and whether it appears to be cost-effective from a business perspective
  • Foundations phase - to understand scope, how it will be carried out, by whom, when and where. Also determines how the DSDM process will be applied to the specific needs of this project
  • Evolutionary Development phase - requires the development teams to apply practices such as MoSCoW prioritisation, timeboxing and iterative development to create a solution that meets both the business need and is built the correct way from a technical point of view
  • Deployment phase - deploy either a subset of the final solution, or the full solution. This phase comprises 3 activities:
    • Assemble - bring together work to be released
    • Review - a final review to ensure release meets appropriate standards. A retrospective is carried out at this stage, focussing on ways of working and potential areas for improvement
    • Deploy - the physical act of putting the release into operational use (e.g. onto a production environment)
  • Post project phase - checks how well expected business benefits have been met
DSDM lifecycle
DSDM lifecycle showing phases


DSDM has quite a number of roles, 15 to be precise including:

  • Visionary - has good understanding of business objectives. Provides guidance to keep project in right direction
  • Technical Coordinator - responsible for designing system architecture and maintaining technical quality of the system
  • Developer - includes analyst, designer, programmer and tester
  • Ambassador User - one of the people who will use the system. Has the ability to convey both the needs of the users to the development team and progress of developed system back to the other users
  • Advisor User - as the ambassador user cannot represent all user groups, a secondary user can contribute by giving specific project related information
  • Executive Sponsor - person from customer’s organisation, has responsibility regarding the financial budget for the project

What makes DSDM ‘Agile’?

DSDM’s philosophy states that:

“best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.”

This relates very strongly to the principles behind the Agile Manifesto, in particular:

  • Deliver working software frequently
  • Build projects around motivated individuals

In addition, DSDM is an iterative approach to software development, which uses both controlled timeboxes and feedback loops. Iterative Development is at the heart of Agility and follows a fundamental cycle of Identify, Plan, Evolve and Review - which can definitely be seen throughout the entirety of the DSDM lifecycle. There’s so much more that is ingrained in DSDM which I haven’t mentioned here, such as MoSCoW requirements analysis, Risk and Configuration Management - but I don’t wish to write out the entire DSDM Handbook in this blog post, so I’ll let you check that out in your own time and move onto another Agile approach…


Let me start off by saying that I haven’t personally come across Crystal being practiced in my professional career, but I’ve definitely used concepts from it.

Crystal is designed to reduce documentation and communication overhead as much as possible, by favouring in-person interactions. Developed by Alistair Cockburn in the early 1990s whilst he was working at IBM, Crystal is actually a collection of methodologies, each with a colour. You choose which colour methodology to go with based on the size of the team and project, and the risk to human comfort, finances, or life. Small projects with little or no risk to human life would go with Crystal Clear, Crystal Yellow or Crystal Orange, with projects of greater risk moving to Crystal Diamond and Crystal Sapphire. The image below shows a table used for selecting some of the Crystal methodologies based on size of the team.

Crystal Family selection table
Table to help determine which Crystal methodology to use for a project

The more people you have on a project, the harder the project will be (moving toward the right of the table), and therefore a darker colour of Crystal is needed. The y axis represents how critical the project is, as you move closer to the top of the table the higher risk to human life there is. The numbers in each of the cells represent the upper size of the project team.


  • Frequent delivery
  • Reflective improvement - there are always areas where the product and process can be improved
  • Close or osmotic communication - co-located teams pick up valuable information without even being directly involved in the discussion
  • Personal safety - open and honest communication helps team members to speak without fear or judgement from others
  • Focus - everyone in the team knows exactly what to work on
  • Easy access to expert users - the developers are able to maintain communication and obtain regular feedback from real users
  • Technical environment with automated tests, configuration management, and frequent integration - to enable errors to be caught quickly


The phases of Crystal depend on which particular coloured approach is followed. They generally follow the Construction - Demonstration - Review pattern but there are many other activities involved. For example, in Crystal Orange:

  • Staging - analysis, feasibility study and prioritisation of tasks
  • Construction - development of the product occurs
  • Demonstration - finished increment is shown off to the team and stakeholders
  • Review - after an increment is delivered, the increment objectives are reviewed to ensure they have been met
  • Tracking - increments are measured at each milestone to determine fluctuations in the development lifecycle
  • Parallelism - stability, work plans and synchronisation are reviewed
  • Holistic Diversity - large functional groups are split into cross-functional groups to create diversity of specialised people to handle different parts of the project
  • Tuning - interviews and workshops held to identify solutions
  • Workshops - to drive team’s attention to project goals


  • Sponsor - allocates money for the project
  • Expert user
  • Lead designer - technical lead, mentors less experienced team members
  • Designer-Programmer - carries out both design work and coding

What makes Crystal ‘Agile’?

Crystal covers many of the principles behind the Agile Manifesto, primarily regarding people. People are the most important aspect of Crystal, which is why each colour varies based on the risk to human life As Alistair Cockburn has stated:

“Crystal is a family of human-powered, adaptive, ultra light, ‘stretch-to-fit’ software development methodologies.”

Again, Crystal is an iterative approach to software development and just like DSDM it also uses controlled timeboxes. As people are at the heart of crystal, users are actively involved and kept up-to-date about the progress of work—sounds like a feedback loop to me! Of course, at the end of each time-boxed iteration some potentially-shippable functionality is delivered, again fulfilling a couple more Agile principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  • Deliver working software frequently

Yep, Crystal definitely ticks quite a number of the “Is it Agile”? checkboxes!

eXtreme Programming (XP)

XP was primarily developed by Kent Beck in 1996 when he was working on a payroll project at Chrysler. It was the dominant agile method in the 1990s and early 2000s, and many software engineering teams still use several of the practices that were made popular by XP. XP values adaptability over predictability; its aim is to lower the cost of change. Changing requirements are seen as an inevitable and natural part of software development, so XP tries to make it easier to adapt to such changes through its values, principles and practices.

XP principles

  • Rapid feedback - get feedback, interpret it and react to it quickly
  • Assume simplicity - treat every problem as if it can be solved very simply
  • Incremental change - small changes work better than big ones
  • Embracing change - changing requirements are an opportunity, not a problem
  • Quality work - a team that works well feels proud of what they deliver


  • Planning - define requirements, create user stories, estimate and prioritise
  • Designing - define main features of the future code
  • Coding - the most important phase with continuous refactoring to keep code simple and maintainable
  • Testing - happens alongside coding and involves both unit testing and customer acceptance testing
  • Listening - customer feedback to guide future iterations
XP lifecycle
Typical XP cycle


A typical XP team includes 6 roles:

  • Customer - creates user stories, sets priorities and maintains the product backlog
  • Programmer - writes code, performs project tasks
  • Coach - watches team’s work, coaches team to implement the most effective practices
  • Tracker - monitors progress of software development and detects problems in it
  • Tester - responsible for product testing and utlimately the quality of overall product delivered
  • Doomsayer - tracks risks and warns team about these

What makes XP ‘Agile’?

XP uses iterations which are typically 1-2 weeks in duration. XP puts a lot of focus onto engineering practices, such as test-driven development (TDD), continous integration and deployment (CI/CD), pair programming, refactoring, and simple design. These are in line with several of the Agile principles:

  • Continuous attention to technical excellence and good design enhances agility
  • The best architectures, requirements, and designs emerge from self-organizing teams
  • Simplicity—the art of maximizing the amount of work not done—is essential

The 5 values of XP are also crucial for understanding this methodology and how it relates to Agile:

  • Simplicity - do what is needed and asked for, but no more. Keep the design simple and clean
  • Communication - daily face-to face discussion
  • Feedback - deliver working software at every iteration
  • Respect - everyone contributes value even if it’s simply enthusiasm
  • Courage - tell the truth about progress and estimates
XP values
5 values of XP

It’s very obvious that many of the XP values align closely with the principles of Agile, which isn’t a surprise when you consider that several of those behind XP also helped to write the Agile Manifesto.

A comparison of these 3 methodologies alongside Scrum and Kanban

MethodologyProsConsBest used in

Business value is the highest priority deliverable

Specific approach (MoSCoW) for requirements prioritisation

Smooth system implementation

Significant and continuous user involvement

Expensive to implement

There's a lot to DSDM which makes it difficult to explain

Requires development team to have both business and technical skills

No specific focus on IT technical practices

Large business-change or highly regulated projects

Where you have lots of roles and specialist skillsets, such as Business Analysts and Solution Testers

Where you have full management commitment

Co-located teams, or where teams are able to meet and work together often and easily


Can be adjusted based on project type and team size

Encourages risk analysis at the beginning of a project

Supports fixed price contracts

Lack of case-studies and materials for Crystal methodologies other than Crystal Clear (smallest one)

May not work well for distributed teams

Moving from one flavour of Crystal to another mid-project is not possible

Project-based approach may mean switching frameworks often

Co-located teams for osmotic communication (overhearing discussions to pick-up relevant information)

Development team have easy and readily available access to expert users


Trusts development team

Promotes engineering practices for quality software

Split roles for business vs. technical decisions

Effectiveness heavily relies on people involved

Does not measure code quality assurance, may cause defects

Excessive changes may be adopted too frequently

Small teams (up-to 12) of experienced developers

Highly adaptive environments (requirements change rapidly)

High availability of customer participation


Clear visibility through Scrum meetings

Increases team's accountability for what is delivered

Team can adapt to changes quickly and easily

Requires strong commitment from all team members

Progress can be negatively impacted if a team member leaves or is absent mid-sprint

Requires highly experienced team to run smoothly and prevent scope creep

Teams that don't get many interruptions from everyday business

Highly skilled and efficient team (cross-functional, generalists/specialists)

Small teams of 3-9 people who have a lot of self-management and collaboration skills


Adaptable due to event-driven workflow rather than timeboxed iterations

Simple to understand and gets started with

Higher flexibility than other methods - allows you to add new items where capacity allows

Work-In-Progress (WIP) limits improve the flow of work items to be delivered ("stop starting, start finishing")

Lack of timing - no timeframes associated with each phase

Easy to overcomplicate the Kanban board with too many categories or card types

Requires discipline - keeping the board up-to-date, reviewing WIP limits and unblocking work items

Usually not enough by itself and tends to be combined with other approaches

Dynamic work backlog, for example support teams

Have reached a mature level with many business as usual tasks, defects and smaller unrelated user stories

Have many unscheduled releases

Of course, these are just three methodologies! There are several others I haven’t explored here, such as Feature Driven Development (FDD), Rapid Application Development (RAD), and several which have interated on Rational Unified Process (RUP), such as Agile Unified Process (AUP) and Disciplined Agile Delivery (DAD).

As practitioners of Agile, our responsibility is to use the right techniques for the problem at hand. It’s my belief that sticking to a single methodology is an unnecessary restriction when there are so many others out there; studying each of these allows us to pick and choose the best ideas from each.