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.
Abstract
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.
Contents
The manifesto for agile
software development
Dynamic System Development
Method
An 11th principle:
continuous integration
Four more agile principles –
nobody could dispute
Three
more agile principles – contrary to centralisation
What’s wrong with being all
things to all people?
Conclusion: our quality plan
for agility
This manifesto <http://www.agilealliance.org>
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:
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.
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.
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.
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.
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
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.
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.
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.
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.” <http://www.martinfowler.com/articles/continuousIntegration.html>
How empty is Fowler’s virgin machine? Does it have an operating system on it? What else?
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? |
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.
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.
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.
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.
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.
“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 |
Discussion |
|
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: http://avancier.website”
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 http://creativecommons.org