The agile manifesto and more: a ten point quality plan

This is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.



EA frameworks encourage people to draw up and maintain comprehensive plans and specifications.
Agile software developers discourage them (and encourage reliance on developers).
Extremists in each school (say, John Zachman and Scott Ambler) hold irreconcilable positions.
The challenge for our profession is to work out where the best compromise lies. 

That's what makes a study of these matters interesting.

This paper distils what I think matters most from several attempts to formalize what agile development means.

Sources include the agile software development manifesto, XP’s development-oriented principles and DSDM’s management-oriented principles.


The manifesto for agile software development 1

Dynamic System Development Method. 3

An 11th principle: continuous integration  3

Four more agile principles – nobody could dispute  4

Three more agile principles – contrary to centralisation  5

What’s wrong with being all things to all people?  6

Conclusion: our quality plan for agility. 6


The manifesto for agile software development

This manifesto <> presents the consensus view of several agilists about the values and principles they look for in a successful project.


We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


This paper elaborates on these four values.

It focuses on what is remarkable, and perhaps controversial, about agile projects

(Not to repeat motherhood and apple pie that agile methods share with non-agile methods.)

In short, a project team that follows all ten principles below would have to be regarded as highly agile.

Headline statement

Ten principles for your quality plan

Fail faster is good.

If we are going to fail, we want to fail faster.

We use prototypes to tackle risks early.

Value individuals and interactions over processes and tools.

We empower a small team (including users) to get on with it.

We maintain continuous and close stakeholder involvement

Value customer collaboration over contract negotiation.

The customer must be willing to change and sacrifice requirements.

We get customers on side before we start

Value responding to change over following a plan.

We develop iteratively, driven by priorities.

We iteratively refactor code written so far.

Value working software over comprehensive specifications.

We focus on program code rather than on specifications.

We focus on tests rather than on specifications.


Chris B: I like your points and they seem to me to be a fair reflection of agile practices.

Michael Z: This list gets down to brass tacks, and can be reflected in concrete project practices, and in the quality plan up front.


You will surely agree that a project that can say yes to all ten principles in this table would have to be regarded by as highly agile.

A value of these ten imperatives to a manager lies in their simplicity.

Starting with these as clear statement of intent, we can look at the situation in front us, then adapt the agile approach accordingly.

Fail faster is good

If we are going to fail, we want to fail faster

We use prototypes to tackle risks early.


A failed agile project is much cheaper than a failed sequential/waterfall project – because it fails faster!

Agile methods weed out ill-conceived projects, through iteration and short-term delivery milestones.

Nobody wants to fail, or be seen to fail; it is human nature to put off the day when failure is exposed.

That’s one of the reasons why being agile can be tough – it isn’t the easy option some people assume it to be.

Value individuals and interactions over processes and tools

We empower a small team (including users) to get on with it.

We maintain continuous and close stakeholder involvement.

Note that communication about technical things is assisted by references to specifications documented using tools.

Value customer collaboration over contract negotiation

The customer must be willing to change and sacrifice requirements.

We get customers on side before we start.

Note however that the normal context for IT service providers is a detailed contract.

Value responding to change over following a plan

We develop iteratively, driven by priorities.

We iteratively refactor code written so far.


Waterfallists disapprove: “Agile is, in my mind, as much an excuse to cover for not knowing what a problem is or how to go about understanding it as it is a methodology. 

From what they say, we wouldn't be very agile if we had a plan.”


Agile development is based on idea that scope can, will and should creep.

“Agile development is a close cousin to the lean manufacturing concepts pioneered by Toyota in the mid-80's and early 90's.

The concept is simple – keep work in process to a minimum in order to discover and improve mistakes with a minimal amount of waste and rework.

Agile development likewise seeks to keep work in process to a minimum in order to avoid large scale mistakes in architecture and feature design by facilitating rapid feedback throughout the value chain – from the developer, to QA and release, and ultimately to the customer.

It has the side benefit that products that rapidly evolve to deliver ever greater value to the customer become “stickier” and less prone to competitive displacement.” (Ref. 4)


Agilists welcome change requests, because they show the customers and users are clarifying their business needs.

Customers realize what they really want when they see the solution take shape.

And change requests describe their requirements more accurately than what they said in interviews before development started.


Agilists do make plans, chunked into short time/cash boxes.

But since they assume the plans will change, they don't detail later phases much as the first.

In Scrum for example, only the next 30 day sprint is planned in any detail.


Agilists emphasise the need for slick change management.

They deprecate bureaucratic change control that has the effect of restricting the changes (that is, improvements).

Because to resist change means resisting building the solution the customer really needs.

And you may end up building the perfect solution to the wrong problem.


Agilists continually juggle priorities.

If a change is substantial and important, then you must ask the customer to de-prioritize something else to make way for it.

Read “Configuration management challenges” for more discussion.

Value working software over comprehensive specifications

We focus on program code rather than on specifications.

We focus on tests rather than on specifications.


There is a lot to be said about this last principles, which is apparently contrary to enterprise architecture.

Read Value working software over comprehensive specifications for detailed discussion.

Dynamic System Development Method

Agile principles were first described in the early 1990s.

One of the earliest agile methods, DSDM, promoted 9 principles, mostly similar to those discussed above

DSDM was originally presented as a RAD method.

Nowadays, agilists deprecate the term RAD, because it appears to promise that you can get the same result quicker.

RAD methods were indeed about producing a system quicker, but not necessarily the system the customer first envisaged (which may prove undeliverable).

Rather, the aim is to deliver a system that does what matters most, and is deliverable.

The key to DSDM, and agility in general, is flexibility about requirements.

This and other DSDM principles can largely be subsumed under the umbrella of the agile alliance.

An 11th principle: continuous integration

We have chosen ten principles of a fairly general nature.

There more at the level of software engineering disciplines.

Continuous integration is promoted, especially by Martin Fowler.


“Continuous Integration is a software development practice where members of a team integrate their work frequently.

Usually each person integrates at least daily - leading to multiple integrations per day.

Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”


“Continuous integration might be seen as merely an elaboration of the principles in the previous three sections.

It is however a big and powerful step change from waterfall methods.

 Properly done, it forces teams (customers, managers and developers) to face up to the real state of their evolving product (the software).

And reinforces the rapid feedback loops at the heart of agile efficiency claims.”


“The main continuous integration practices:

           Maintain a Single Source Repository

           Automate the Build

           Make Your Build Self-Testing

           Everyone Commits Every Day

           Every Commit Should Build the Mainline on an Integration Machine

           Keep the Build Fast

           Test in a Clone of the Production Environment

           Make it Easy for Anyone to Get the Latest Executable

           Everyone can see what's happening

           Automate Deployment”


“A common mistake is not to include everything in the automated build.

The build should include getting the database schema out of the repository, and firing it up in the execution environment.

I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.” <>


How empty is Fowler’s virgin machine? Does it have an operating system on it? What else?

Four more agile principles – nobody could dispute

The table below lists four more principles that are reasonable - so reasonable it is hard to imagine many wanting to promoting the alternatives.

That’s why I don’t regard them as distinguishing an agile project from non-agile projects, and they didn’t make our top ten.

Four agile principles that didn’t make our top ten

Is alternative conceivable?

Agile processes promote sustainable development.

Promote burn out and non-sustainable development?

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Drive sponsors, developers, and users until they are too tired or disheartened to carry on working?

(Though of course hard deadlines must be met, and people do work better under a bit of pressure now and then.)

Continuous attention to technical excellence and good design enhances agility.

Attention to technical excellence and good design is bad? gets in the way?

Simplicity--the art of maximising the amount of work not done--is essential.

Needless complexity is a good idea?

Three more agile principles – contrary to central planning

There is a school of agilism which is opposed to centralised top-down command and control as a matter of principle.


“Traditional development governance frameworks have had limited success because developers are intellectual workers who don’t work well under command-and-control approaches.

To be effective, a governance program must reflect the actual environment in which it is being applied, and take into consideration the people involved.” Scott Ambler

“Successful development governance focuses on enabling the right behaviors and the best practices through collaborative and supportive techniques.

It proves to be far more effective to motivate people to do the right thing instead of forcing them to do so.” Scott Ambler


This school promotes the three principles below.

You can see where they are coming from, but they don’t feature our top ten.

Not only designs but also practices are flexible

A view expressed in agile modelling discussions is that agility is not about any set of practices; it means being able to change your practices whenever you feel the need.

That is certainly “agile” in a sense.

But should managers measure the agility of a project by how frequently it changes its practices?

The danger here is that agility descends into trial and error.

The focus of agility is on promoting high-communication environments

This is a valuable focus. Communication is certainly a worthy topic to address.

Communication of requirements and designs is a challenge, and essential, on every software development project, be it agile or waterfall.

Poor communications cause difficulties in many projects.

The environment should not prevent communication.

Note that high communication per se can be a symptom of problems.

Above the critical mass of the agile team, we run into the “mythical man month” problem discussed in our paper on change management challenges.

Since agile methods involve prioritizing and narrowing of scope; they explicitly remove some topics of discussion.

Note that agilists deprecate some communication paths.

Some complain that adding an extra layer of communication with design authorities and enterprise architects prevents agility.

This brings us to one more agile principle.

The best architectures, requirements, and designs emerge from self-organizing teams

This is true only to an extent and in some contexts. It wraps up three or four ideas in one sentence.

It appears to suggest a project team should resist the advice of design authorities, technical risk reviewers – and enterprise architects.

I’ll leave that for discussion in other papers.

What’s wrong with being all things to all people?

The last three principles above are not wrong.

However, they can encourage the anything-goes school in which everybody discusses everything and developers do whatever they choose.

If agile becomes everything and nothing, then it becomes recipe for methodology mayhem.

What is it saying to customers? 

·         We aren’t trained in recognised practices?

·         We don’t have or follow consistent practices?

·         We aren’t responsible for past mistakes?

Would you let your mother into a hospital run this way?

Would you put your car into a repair shop run this way?


An enterprise wants agility to be objective in its theory, and useful in practice.

Anybody promoting any methodology ought to be pressed by senior managers to provide objective answers two questions:

How can I tell whether a project is applying this methodology or not?

How will I know a year from now whether my projects are more or less cost effective as a result of following this methodology?


What is an agile project? If we can’t give our managers some objective ways to distinguish agile projects from non-agile ones, then we do not deserve to be taken seriously.

If agile is important, then our managers should be able to recognise a highly agile project.

In order to place a project on the spectrum from low to high agility, managers need specific criteria they can readily assess if not measure.

Conclusion: our ten-point quality plan for agility

“I typically start with a known set of Fairly Good Practices, then when one of them fails, find out why and fix the problem.

The funny thing is that because I choose XP [extreme programming] as my starting point, and because I recommend others use XP as their starting point, I am often branded a zealot.

This makes me sad, then angry.

Angry because I don't think I ought to be labelled a zealot just because I use the same starting set of practices for each project – something I have seen work." J.B.Rainsberger,


If you want agile methods to have a positive and significant impact on a large organisation, then I propose you:

·         Define a platform of agile disciplines (like our ten imperatives) as a common starting point.

·         Exclude any principle that is bland, middle-of-the-road, all-things-to-all-people, motherhood and apple pie.

·         Extend the agile platform with advice on specific challenges and compromises (see later discussions) that lead projects away from being highly agile.

·         Get managers' agreement that your agile platform, challenges and compromises are taught to all, from the top down.


You will surely agree that a project that can say yes to all ten principles in this table is highly agile.

Ten imperatives for agility


1) If we are going to fail, we want to fail faster

Knowing that software projects are difficult, and a high percentage end up failing, fail faster is good.

Agile methods help us more swiftly spotlight daft requirements, poor process and ignorance of technologies.

2) We develop iteratively, driven by priorities

The agile manifesto principle is: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.”

An agile project proceeds in increments. SCRUM speaks of 30 day increments.

Some projects (probably well into construction if not maintenance) get to work on the basis of daily increments.

3) We use prototypes to tackle risks early

RUP and other methods say use prototypes to tackle any tricky design risk early.

4) We empower a small team (including users) to get on with it

The agile manifesto principle is: “Build projects around motivated individuals.

Give them the environment and support they need, and trust them to get the job done.” This does of course imply the team has the necessary skills.

SCRUM speaks of self-managing teams. DSDM speaks of empowered teams.

Users and developers should work cooperatively in a team empowered to make decisions.

The people typically appointed to steering groups and project boards rarely have the knowledge or the ability to direct the development team on a day-to-day business.

They should be (and are in PRINCE2) a body to handle exceptions elevated to them.

5) We maintain continuous and close stakeholder involvement

The agile manifesto principle is: “Business people and developers must work together daily throughout the project.”

6) We focus on program code rather than on specifications

The agile manifesto principle is: “Working software is the primary measure of progress.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

In XP, analysts record requirements on cards, which are allocated to developers.

Analysts talk to the developers about what the requirements mean.

Further documentation effort is focused on what is executable, or testable.

Agile methods are light on documentation; there is little by way of functional specification or UML.

Where code has to be documented, reverse engineer some UML and erase details until you have something readable.

7) We focus on tests rather than on specifications

The XP practice is for developers to write unit test code before solution code.

Also, analysts specify system test data rather than system/functional specifications.

8) We iteratively refactor code written so far

This is an implication of iterative development promoted by Martin Fowler, Scott Ambler and Bob Martin.

Refactoring means restructuring a process to make it more economical, more optimal.

Refactoring is usually and preferably done during a change made for requirements reasons.

(If done afterwards, there is an additional regression testing burden.)

9) The customer must be willing to change and sacrifice requirements

The agile manifesto puts it thus: “Welcome changing requirements, even late in development.

Agile process harness change for the customer's competitive advantage.”

A DSDM guru would put it. “What gives is what the customer gets” (Jennifer Stapleton)

Given we time and/or cash box our delivery, we (customer and supplier) must be flexible about requirements.

10) We get customers on side before we start

The agile manifesto doesn’t say this, but agilists ignore it at their peril, and it is a feature of DSDM at least.

You must first ensure sponsors and customers are committed to all of the above principles.


Remember these are imperatives for agility, not for every project.

You can set out with these imperatives, then adapt according to circumstances.

Other papers discuss difficulties that tend to undermine these imperatives, and look at applying them to a large-scale systems integration programme.



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0     07/02/2015 16:57

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.


No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this work, not derivative works based upon it.

For more information about the licence, see