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.

Principles

• 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

Phases

• 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

Roles

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…

Crystal

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.

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.

Principles

• 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

Phases

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

Roles

• 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

Phases

• 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

Roles

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

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