This is an article I wrote some years ago when I was trying to get my head around “What is Agile?” and “What is the difference between the different methods?”. It is a bit dated now but I’ve kept it on the website as the third question “Is Agile good Project Management?” is still what I’m concerned about.

A Tour of Agile Software Development from Scrum to DSDM via XP and Crystal Orange.

• Generic Agile Life Cycle
• Project Initiation
• Project Planning, Estimating and Budgeting
• Roles and Responsibilities
• Controlling the Project
• Managing Change
• Managing Quality
• Managing Risk
• Reviewing the Project
• Development
• Conclusion

---

So what is Agile Development?

The Agile Manifesto offers a philosophy for Agile Development, and although philosophy is fine for underpinning practice I was more interested in what I should be doing. With that in mind I set out to answer the question:

• What am I doing different if I’m doing Agile Development?

You will notice that I’m not asking which is the best method – so don’t expect to see a rating for each at the end – I’m just interested in comparing the methods to come up with general conclusions about Agile practice.

This aim is a bit tricky as the Agile Alliance is 17 people representing 7 different methods (XP, Scrum , Crystal Orange, DSDM, Adaptive Software Development, Feature-Driven Development, and “pragmatic programming”). Some methods don’t address particular concepts, and even where they do share the same concept the methods differ in terms, parameters and mechanisms. Given the diversity of methods I had to look for similarities and differences to get my overview of Agile.

---

Is Agile good project management?

But knowing what is Agile is really only half the issue, and given I’m a project manager I also have to be happy with the method. That means I’m also looking for an answer to:

• Is Agile good project management? Does it cover the PM bases?

To answer this I used the aspects of project management covered by Watson (1998) – not that Watson is a particular authority, this book was just nearby and seemed to mention all the bits. So for Agile Development to get the big project management tick I’m looking for:

• Project Initiation
• Project Planning, Estimating and Budgeting
• Roles and Responsibilities
• Controlling the Project
• Managing Change
• Managing Quality
• Managing Risk
• Reviewing the Project

I’ve used this list to structure my comparison.

---

Introduction to the Methods

I’m only going to compare four Agile methods: Scrum, XP, Crystal Orange and DSDM. My criteria for selection is no more sophisticated than being more familiar with these than other Agile methods. Each of the methods has a particular slant, which is largely a result of where it is invented, by whom, and for what type of project.

A later section lists the books I used as a basis for comparison.

Scrum

Pitched as: “Management and control process that cuts through complexity”
Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior managers wanting to get product out faster.
Where invented: USA
Year first used: 1994
First used on: Advanced Development Methods – process automation software. 8 developers. VMARK – OO software development environments.
Now used on: All over the place with different groups/people.

XP

Pitched as: Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements Invented by: Kent Beck who preferred being a Technical Lead to being a Project Manager. Where invented: USA
Year first used: Pre-2000
First used on: C3 project Chrysler; 8 developers.
Now used on: All over the place by different groups/people.

Crystal Orange

Pitched as: A method to run “a cooperative game of invention and communication, with a primary goal of delivery useful working software and a secondary goal of setting up for the next game”
Invented by: Alistair Cockburn – A self proclaimed methodologist who also manages projects.
Where invented: USA (I think, although he is a Brit)
Year first used: Pre-1988
First used on: Project Winifred; team of 20-40.
Now used on: Not used again. A variant Crystal Orange Web used at eBucks.com.

DSDM

Pitched as: “A framework of controls and best practice for rapid application development”
Invented by: DSDM Consortium
Where invented: UK
Year first used: 1995
First used on: Don’t know but been used at/by BT, Orange, Dept. of Health, Syndeco/Boston Globe, Sema Group, Logica and British Midlands.
Now used on: All over the place with different groups/people.

---

Generic Agile Life cycle

Since I wrote this article I have updated my thinking on an Agile Lifecycle / Agile Heartbeat.

All software development methods, including the Agile ones, have some sort of underlying project life cycle. Some of the Agile methods don’t make a big deal of it, and others do. Some have such abstract life cycles that it is actually hard to know what activities to schedule. And they all use different terms for the same thing.

I’ve come up with a generic Agile Life Cycle. Showing it here is a bit like telling you the answer before asking the question, however as it provides a common framework to explain some similarities and differences between the specific methods I thought it worth putting in early. The key elements are a Project Initiation and Project Plan followed by one or more Releases made up on one or more timeboxes (although usually 3). There are also more or less optional phases to Elaborate Requirements and for the Architecture – often done in parallel with the Project Plan. Perhaps not so strangely, this life cycle looks pretty conventional.

Project Initiation

Set up and justify the project. Determine initial high level requirements.

Project Plan

Plan out the project, everything after Project Initiation, including whether you’re going to have the optional phases.

If you’re using the optional phase to Elaborate the Requirements you’re likely to have a draft plan after the Project Initiation and then a more complete plan after the Requirements are complete. DSDM makes this explicit and mandatory with its “Outline Plan” (created in Project Initiation) and “Development Plan” (created after the Requirements have been fleshed out). XP has something similar in the “Big Plan” done to justify a project, which evolves into a Release plan.

Elaborate Requirements (optional)

Very high level requirements are gathered during Project Initiation. These can optionally be expanded during an phase to Elaborate Requirements. Even is the requirements are “elaborated” they are still high level.

There is no separate Elaboration phase in XP and Scrum, although the Customer is expected to elaborate as much as necessary at the start of an XP Iteration (Timebox).

Crystal Orange and DSDM have a separate Elaboration phase. Facilitated workshop(s) to identify “High level requirements” which are then collated into a document (Requirements Document / Business Area Definition (BAD)) that contains use Cases and non-functional requirements.

Architecture (optional)

The Agile approach is generally design for today and refactor tomorrow (at least in XP). An Architecture Phase is optional in XP and Crystal Orange. However, In DSDM An architecture phase is compulsory and results in a “System Architecture Document”. The SAD is created in parallel to the BAD, i.e. requirements elaboration and architecture occur at the same time.

Release

A Release is a piece of development where the customer gets some new software. Releases can be from 2 weeks to 6 months, but are usually 3 months long. Release have one or more timeboxes. Unlike other methods, in DSDM one Release is the norm, i.e. there is only one release to the customer in the entire project.

Time box

A Timebox is 1 – 6 weeks long, but usually 3 – 4 weeks. The most important thing about a timebox is that the delivery date is fixed.

---

Project Initiation

There are some important questions to be addressed at the start of any project. Project Initiation is the phase where these questions are addressed.

Scope Project: Should we invest more?

Probably the key question during project initiation is “Should we invest more?”, i.e. is the project worth going ahead with? Normally, if this question is addressed at all, it is covered as part of a business case.

Not all Agile methods address this question. DSDM includes a business case in the Feasibility Report. XP addresses cost benefit for the overall project with a “Big Plan” in the early stages. Scrum and Crystal Orange don’t mention it.

Choose the right method

Having decided to continue with the project the next question is what method to use.

XP says to use XP for vague or changing requirements and leaves it at that.

The DSDM manual includes a list of suitability characteristics and the PM must use these to decide if DSDM is appropriate for the project (and document this decision in the “Feasibility Report”).

Scrum claims to be for any project. A big claim!!

Crystal Orange says to pick a method that is barely sufficient to match the needs of the project. Cockburn offers a categorisation of methods and projects to help with this decision.

Choose your formality

Part of the decision about which method is what level of formality is appropriate for your project. Even within the Agile Methods there is a spectrum of formality and the number of different types of document give an indication of this formality:

Define a vision to point the way

Often with software development there are just too many choices for what the team could do. Vision statements can help remove this confusion by pointing the general direction in which the team is meant to head. The Agile methods use vision statements, although the level at which they are used differs.

XP uses a “Metaphor” as a product vision, for example, the new product is like a spreadsheet. This helps everyone understand basic elements of the product and their relationships.

In many ways DSDM’s “Feasibility Report” is a project vision as it defines general scope and objectives.

Scrum’s “Sprint Goal” is a timebox vision. It gives a Scrum team some wiggle room regarding functionality.

High Level Requirements – Fast

---

Project Planning

I believe that Agile Development is all about Project Management, so it is no surprise that an Agile Project Plan is a wee bit different to the norm.

If you’re using the optional phase to Elaborate the Requirements you’re likely to have a draft plan after the Project Initiation and then a more complete plan after the Requirements are complete. DSDM makes this explicit and mandatory with its “Outline Plan” (created in Project Initiation) and “Development Plan” (created after the Requirements have been fleshed out).

Planning based on Timeboxes

The Agile methods are fairly unified on their approach to project planning. Agile projects have Releases made up of Timeboxes, and these elements form the basis of the project plan.

A Release is a piece of development where the customer gets some new software. Releases can be from 2 weeks to 6 months, but are usually 3 months long. Release have one or more timeboxes.

A Timebox is 1 – 6 weeks long, but usually 3 – 4 weeks. The most important thing about a timebox is that the delivery date is fixed.

Unlike other methods, in DSDM one Release is the norm, i.e. there is only one release to the customer in the entire project. DSDM is also unique in that it categorises tiimeboxes depending on their function: Investigate, Refine, Consolidate. There are more of the former at the start of a project and more or the later at the end.

Developers do initial project estimates

In Scrum Owner estimates Backlog items in days (with help of developers).

XP developers, preferably as a group, estimate size of a Story in Ideal Days/Weeks/Months.

DSDM and Crystal Orange takes a more conventional approach. Project Manager and Developers estimate effort derived from size. Crystal Orange uses estimated number of classes as the size measure, and DSDM typically uses Function Points. A Crystal Orange PM might do a second estimate for comparison.

No contingency is needed in developer estimates

No contingency is necessary as requirements that don’t fit are dropped or rescheduled by the Customer. In DSDM the customer does some of this decision making in advance in the form of the MoSCoW priorities.

Project Plan = Requirements in Timeboxes

In an Agile project the customer, assisted by the team, assigns Requirements to Timeboxes based on size of team and estimates

I call this bucket planning in the sense that each timebox is a bucket with a certain size. You can put requirements into the buckets but if a bucket is full, you can’t put anything more in it.

DSDM adds the restriction that each timebox must contain some Must Have requirements (in the MoSCoW priority scheme) with some lower priority items. Essentially in DSDM the Must Haves go into the bucket first, then the Should Haves, and finally the Could Haves. The Would Like to Haves don’t make it into the bucket at all.

Timebox Plan built by team

The Agile methods agree that each timebox has a plan of its own that is created in a meeting at the start of the timebox. Details differ.

An XP Iteration (timebox) has an “Iteration Planning Meeting ” where the customer explains the Stories (requirements).  The team list tasks and programmers sign up for tasks.

Scrum has a “Sprint Planning Meeting” at the start of each Sprint (timebox). The Team picks Backlog that is achievable (the “Sprint Backlog”) and decides how to achieve Sprint goal within the Sprint.

DSDM has an objectives setting meeting at the start of a timebox. Users reassess MoSCoW priorities, the team agrees quality criteria, and the team agrees minimum that can be delivered.

---

Roles and Responsibilities

Small Cross-functional teams

Team Composition and Roles in the Agile Methods

Concept	XP	Scrum	Crystal Orange	DSDM
Number of teams	1 team per project	1 – 4 or more	Variable; up to 40 people so probably 1 – 10 or so.	1 – 6
Team size	3 – 16	5 – 9	4 – 8	2 – 6
Team Members / Roles	Customer, Programmer, Tester, Tracker, Coach	Scrum master, Experienced Engineer, Junior Engineer, [QA Tester], [Writer]	Business Analyst-Designer, Designer-Programmer, UI Designer, [Tester ]	Team Leader, Ambassador User, [Advisor User], Senior Developer, Developer, Scribe
Project Roles	Big Boss	Project Manager/ Scrum master, Product Owner	Sponsor, Project Manager, Architect, Technical Facilitator, Design Mentor	Visionary, Executive Sponsor, Project Manager, Technical Co-ordinator, Facilitator

Agile Developer – Life in a different world

As an Agile developer you undertake a variety of tasks (analysis, estimating, design, coding, testing) and generally do what it takes (which is pretty much all Scrum uses for a job definition). You are Client facing, in fact client facing every day as the customer is one of the team. There is less documentation to write, unless you want it. There is stress, e.g. short time frames, but this is managed (for example, XP’s 40 hour week). On the other hand there is more visibility of your own work and progress: Pair programming (XP), Peer Reviews (DSDM), User Reviews (XP, Scrum, DSDM), Daily meetings (XP, Scrum). You work faster and produced better quality. You’re part of a team with a shared aim and shared responsibility.

User/Customer – An Active Role

Life is different for an Agile Customer as well. You are part of the team and must actively participate. You are responsible for the requirements. You must Talk to other users and get their agreement, Write up the requirements (if necessary), and explain them to developers. You have a planning role too as you must prioritise and trade off requirements. During development you provide input into design and prototyping sessions. As the software is produced you must review and accept delivered functionality; you must also organise, control and do user testing. Finally you must provide user documentation and handle user training.

Project Manager as Shepherd

The role of the Project Manager is subtly different when using an Agile approach. From my fairly biased view an Agile PM is more a shepherd (or sheep dog) and less a military officer. There is lots of rushing around the edges of the development team but relatively little direct control of what the team does. If you merge together a description of the Project Manager, Scrum Master, Coach, and Tracker from XP, DSDM, Crystal Orange and Scrum you get:

Gather information from all stakeholders and integrate into workable plan; log estimates; advise programmers on their estimates using historical figures; log task assignments; sustain high rate of progress; make decisions; remove impediments; build and sustain team culture; ensure team sticks to process; liaise between management and team; manage customer relationships; fend off “feature creep” and other project hazards; get agreement on the prioritisation of requirements and detailed content of timeboxes; track progress against the timebox goals/plan; collect information without disturbing the process; update plans; communicate progress; ensure that the lessons are learnt; log defects; stay calm.

Things like “remove impediments” and “build and sustain team culture” aren’t normally seen in traditional PM role descriptions. Then there are the softly, softly items like “collect information without disturbing the process” and “get agreement on …”; and notice we “log task assignments” we don’t “assign tasks”. However, when the crunch comes we must still “make decisions”.

---

Controlling the Project

Produce Product quality releases

XP and Scrum allow the customer to declare a product “done” at any time. This could be because: the competition just shipped, the company needs the cash, the user/customer needs the functions, and/or that was when it was promised.

Simple and direct communication is key

Intra-team communication

• Co-location in open area
• Daily Stand up meeting (XP), Daily Scrum meeting (Scrum)
• Big visible charts (XP), Backlog Graph (Scrum), Information Radiators (Crystal Orange)

Inter-team communication

• Co-location in open area
• Daily Scrum of Scrums meeting (Scrum)
• Big visible charts etc
• “Inter-team spec” (Crystal Orange)

Management reporting

• Frequent delivery
• Big visible charts etc
• Scrum Observers (Scrum)
• “Status Report” (Crystal Orange)

The big visible chart shown is a Sprint Backlog Chart from Scrum. The X-axis is the day of the Sprint (timebox) and the Y-axis is the remaining work in days (Scrum calls this a backlog).

---

Change Management

Within the Agile world, change is expected and time is considered more important than functionality. So if something has to give to allow change, then functionality/scope loses and time wins, i.e. the customer must make trade offs.

The Customer directs development in timebox and minor changes are just accepted. Big changes are handled different depending on whether you’re in a timebox or outside it, and depending on the method you’re using.

Big changes outside a timebox

• Customer can add/remove/change any requirement
• Developers reestimate
• Customer trades off requirements to fit change in Project Plan

Big change inside a timebox

• Either isn’t allowed at all (Scrum)
• Or customer can trade functionality in/out of timebox.
  • Handle change as a new Story and replan (XP)
  • Use MoSCow priorities which are revised at the 3 objectives Setting Meetings within timebox (DSDM).

---

Quality Management

Quality must be addressed continuously within Agile Development.

There are stated Quality Goals. In XP the Product must pass 100% of unit tests and an acceptable number of functional tests. In DSDM there are documented quality criteria for all work products.

Peer Review is mandatory in XP (in the form of Pair Programming) and common in DSDM.

XP uses Xunit for automatic Unit Tests and insists on tests before code.

In XP and Scrum integration Testing should be continuous and automatic, with a daily build and smoke test.

User Acceptance Testing is in parallel to development. The Customer guides development (XP, DSDM), there is UAT during development (XP, DSDM) and formal reviews during timebox (DSDM) and at end (XP, Scrum, DSDM).

Extra testing activities like performance testing are scheduled in the same way as requirements

---

Risk Management

The Agile process reduces risk

DSDM explicitly demands Risk Management procedure

Agile process reduces level of 5 of top 10 risks:

• Feature creep
• Gold plating
• Short changed quality
• Overly optimistic estimates
• Friction between developers and customers

What about risk of inadequate design?

• Technical risk addressed by “prototypes” (DSDM), “shallow iterations” (Crystal Orange) and “spike solutions” (XP).
• But Architecture is optional in some methods (XP)

---

Reviewing the Project

Some of the Agile methods recommend having a bit of a think about what you did.

XP and Crystal Orange suggest the teams be self adapting. XP does this with 1 –2 hours reflection each Iteration (Timebox); Crystal Orange has a “Team Reflection Workshop” in middle and at end of each Increment (Release).

There is also the issue of the next project – what would it do? This is addressed by a Story Pile (XP), Product Backlog (Scrum), or Project Review Document (DSDM).

---

Development

Agility is not so concerned with the technical aspects of development.

Programming. In some ways Agile programming isn’t so different from normal programming: you still have Coding standards (recommended in Crystal Orange and mandatory in XP, DSDM). In other ways it is different, for example XP’s Pair Programming and Test before code.

Design. In the agile world a simple design is best. Design for today and refactor tomorrow (XP). This is true for on-going design and any initial architecture phase. An initial architecture phase is optional (XP, Crystal Orange); only DSDM makes an architecture phase compulsory. The design format varies by method, it can be as simple as a scribble on whiteboard (XP, Scrum, Crystal Orange), or a formal model (Common Object Model in Crystal Orange and the DSDM “System Architecture Definition” containing a Context Diagram, Process/Data/Object Models, Network Model, etc …). The team has a design expert (XP, Crystal Orange, DSDM).

---

Conclusion

What I was trying to answer …

• What am I doing different if I’m doing Agile Development?
• Is Agile good project management? Does it cover the PM bases?

Agile Development is a set of practices and guidelines

The various Agile methods are quite different but I do see some general patterns. A summary of the Agile process would be:

Initiation

• Scope Project: “Should we invest more?”
• Choose the right method
• Define a vision to point the way
• Capture high level requirements fast

Redefine roles, e.g. active Customer and general purpose developer.

Planning

• Life cycle = Timeboxes grouped into Releases
• Project Plan = requirements in Timeboxes
• Let team build timebox plan
• Developers do estimates

Control

• Visible progress with frequent product quality releases
• Simple direct communication using co-location, Daily team meetings, Big visible charts

Change management via requirement trade offs

Address quality continuously

• Daily build & smoke test
• UAT during development
• Peer reviews, e.g. Pair Programming

Use the process to reduce risk

Make simple designs

Reflect on your process

Agility can be good Project Management

Agile Development can be good project management in the sense that you can pick Agile processes to cover all project management issues and concerns. There are Agile processes to cover:

• Project Initiation
• Project Planning, Estimating and Budgeting
• Roles and Responsibilities
• Controlling the Project
• Managing Change
• Managing Quality
• Managing Risk
• Reviewing the Project

All you have to do is, well, do it.

---

The Books Used

XP

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.

Scrum

Schwaber, K., & Beddle, M. (2002). Agile Software Development with Scrum. NJ: Prentice Hall.

Crystal Orange

Cockburn, A. (1998). Getting Started: Plan the project by milestones. Surviving Object-Oriented Projects: A manager’s Guide [Chapter 4], 77-105. Addison-Wesley.

Cockburn, A. (2002). Agile Software Development. Boston: Addison-Wesley.

DSDM

Stapleton, J. (1997). DSDM – Dynamic System Development Method: The method in practice. Harlow, England: Addison-Wesley.

The DSDM Consortium. (1997). Dynamic System Development Method [3^rd ed.]. Tesseract Publishing.

The DSDM Consortium. (2002). Framework for Business Centred Development: Handbook for DSDM Version 4.1. Author.

General Project Management

Watson, M. (1998). Managing Smaller Projects: A practical Guide. Project Manager Today.