The 12 Agile Principles document outlines 12 foundational principles derived from the Agile Manifesto's 4 basic statements. The principles emphasize delivering value to customers through working software, welcoming changing requirements, frequent delivery in short iterations, collaboration between business and development teams, self-organizing motivated teams, face-to-face communication, measuring progress through working software, sustainable development pace, technical excellence, simplicity, self-organizing teams, and continuous improvement. The document provides explanations and examples for each principle.

1. 1
The 12 Agile Principles
From the Agile Manifesto’s 4 basic statements,
12 foundational principles were derived.
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
7. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
8. Working software is the primary measure of progress.
9. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
10. Continuous attention to technical excellence and good design
enhances agility.
11. Simplicity - the art of maximizing the amount of work not done - is
essential.
12. The best architectures, requirements, and designs emerge from self-
organizing teams.
13. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
The principles are fairly self-explanatory.
Yet, like any principles, it's not always easy to see
how they apply in everyday life.
So what do these 12 principles mean?
Agile201Right out of the box

2. 2
Principle 1: Customer satisfaction
Principle "Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software."
What does
this mean?
• The ultimate test of our work is a satisfied customer. Our
customers are paying for value, so by delivering early and as
continuously as is feasible, we add value from the very start.
• Instead of waiting to the end of a possibly very long project,
value is added - and so our customer is satisfied - from the
start.
• That way, not only does the project pay for itself far more
quickly but many of the pitfalls to which work is subject are
also uncovered quickly, and can be overcome before they
cause major havoc.
Why is it
hard?
• For organisations making the transition from waterfall to
Agile, who are used to large-scale planning exercises,
comprehensive requirements specifications and large teams,
the lightness of the Agile approach can be worrying.
• Where Agilists see flexibility and responsiveness to change,
senior executives, PMOs and business
stakeholders often want to know exactly where and how
their money and resources are going to be used, exactly what
they are going to get, and exactly when.
• It is, as the entire history of software engineering
demonstrates, an impossible set of demands, but Agile is
unlikely to seem like the solution.
• It's not that they don't want rapid, frequent delivery of real
results, it's just that Agile doesn't look much like the way to
do it.
How can we
make it
easier?
• Selling Agile is always crucial to success, and that selling
needs to include not only case studies of similar
organisations where Agile has been introduced successfully
but also effective explanations of why Agile really works.
• Don't just itemise the principles and practices: explain how
they will make us more responsive to change, more likely to
deliver what they want now (rather than a year ago when
their waterfall project started), and so on.
Agile201Right out of the box

3. 3
Principle 2: Welcome change
Principle "Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."
What does
this mean?
• Business people change their minds, and a good
thing too. New opportunities arise, people have
better ideas, priorities change - any number of
reasons to not give them what they asked for
months or even years ago.
• And projects change too - all the time.
Work overruns, designs don't work out - any
number of changes happen.
• Yet few organisations are culturally or politically
capable of responding to this constant shifting of
the terrain.
• Change will happen, and once we accept this fact,
it's not only a powerful weapon in successful
delivery but surprisingly easy too.
Why is it
hard?
• Most organisations find change hard. It's seen as
a kind of failure. That's why few projects are ever
cancelled.
• Change is also difficult. Thinking through the
impact of changes is also hard - often more
difficult than the original.
How can we
make it
easier?
• Change the mindset from "Change = failure" to
"Change = opportunity".
• Any organisation is eager to do its best and avoid
failure, so if the inevitability of change is
understood then our responsiveness to change
becomes a strength.
Agile201Right out of the box

4. 4
Principle 3: Deliver frequently
Principle "Deliver working software frequently, from a couple of weeks to
a couple of months, with a preference to the shorter
timescale."
What does
this mean?
• Not only does delivering early and often maximise the value
Agile adds, it's also a powerful test of the methods we're
using to do it. It flushes out both problems and opportunities
early, making it more likely that our stakeholder will be
pleased with the results.
Why is it
hard?
• As with much else about Agile, the thing that
most frequently makes delivering working software difficult is
the fact that most organisations moving to Agile have
inherited a waterfall approach. That generally leads to
thinking of the end-product as a single unit.
• That leads to big, predefined, hard-to-change architectures,
long, complicated developments cycles, massive test efforts,
white-knuckle deployments, and so on. So it is hard to
rethink the delivery process so that it consists of many small
items - the basis of Agile delivery.
• Of course, not all kinds of solution lend themselves to being
divided into lots of parts that can be usefully and quickly
delivered to the user.
• All-or-nothing solutions are not uncommon, especially where
one system is completely replacing another. But even there,
delivering working parts is frequently still a viable strategy - it
will give us the benefits of proving concepts, flushing out
problems early and adapting to change.
How can we
make it
easier?
• First, sell our stakeholders the benefits of rapidly delivering
real business value: even if delivery is incremental, it still pays
for itself far faster than traditional, late, all-in-one delivery.
• Secondly, train our architects to think in terms of small units
of functionality of value to the organisation rather than big,
technically seductive systems.
• And finally, if even the team doesn't quite 'get it' yet, sell
them a replacement for the all-too-familiar 'death march' as
milestone after milestone passes unfulfilled!
Agile201Right out of the box

5. 5
Principle 4: Work together daily
Principle "Business people and developers must work together daily
throughout the project."
What does
this mean?
• One of the biggest obstacles to delivery is the distance
between the delivery team and the people they're delivering
to. It's not just hard to communicate at a distance; it's even
harder to properly understand one another.
• In a fast-changing world such as business IT, getting close is
invaluable, so we can not only communicate change quickly
but we can learn to appreciate each other's perspective and
avoid problems before they even arise.
Why is it
hard?
• Business people have day jobs. They are busy, they have
other important things to do, and once we've been told what
they want, why do we need to have them constantly coming
back?
• Many business people also think IT has a pretty poor track
record of delivering, and no matter how true that may be
(certainly plenty of IT people would happily point the finger
the other way), this creates a sour relationship in which
collaboration is not only difficult but sometimes positively
unwelcome.
How can we
make it
easier?
• First, encourage an open and welcoming environment. Get
rid of finger-pointing (including behind other people's backs)
and make it clear to our stakeholders that we want to change
our relationship to one of collaboration based on mutual
success. Offer to reset the relationship based on
professionalism and a mutual commitment to each other's
success.
• Next, make sure we really understand why Agile is good for
them, not just for us. After all, if it isn't, why should they
bother?
• And if we don't know why it is good for them (or don't think it
matters) then perhaps we have misunderstood Agile too. It
will not be easy, but it will be worth it.
Agile201Right out of the box

6. 6
Principle 5: Motivation, environment, trust
Principle "Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done."
What does
this mean?
• Agile teams are professionals, and they perform best when treated as
such. They do best when they are fully engaged by the organisation,
when they are free to deliver to the highest standards, when they are
trusted to decide how best to work and, when things get tough, they are
supported rather than punished.
• There is no shortage of research showing that, by recognising this
simple human fact, Agile creates huge increases in productivity, quality,
delivery and value. And any organisation that wants to take advantage of
those advances must start by acknowledging their teams'
professionalism.
Why is it
hard?
• Most of us work in strictly hierarchical organisations. The principle
of these organisations is that the people above tell the people below
what to do - and all too often, how to do it.
• That's not because they are especially well qualified to do so - in fact
there is some evidence that promotion is driven less by the technical or
managerial merits of the promoted than by their cultural fit and political
skills. But the result is entirely predictable - mutual misunderstanding,
followed by the one side using its superior leverage over the other.
• Nor are business people or senior executives often experienced in
working with IT or project/programme management teams, and seldom
seem to 'get' the idea of professionalism or self-discipline, or understand
the technical issues that make systems development a very open-ended
puzzle.
How can we
make it
easier?
• The key is engagement. Work with business people and senior
executives, focusing on what's in it for them. Agile has proved its ability
to add value, deliver quickly, increase productivity, and generally furnish
the organisation with many benefits it simply isn't used to seeing from
IT. There is a price to be paid, of course: a higher level of engagement on
their side.
• So IT needs to develop a realistic appreciation of how difficult that is for
users, business people and other stakeholders, many of whom already
have quite a low opinion of IT's ability to deliver as promised.
• Nor does it help that they will not be able to track progress as they are
used to doing - through the usual phase- or milestone-based reporting
of 'requirements ready', 'design complete', 'system test complete', etc.
• The argument has to be clear, compelling and focus on their needs, not
just ours. It will also be helpful to strike up alliances with other groups in
similar positions to ourselves, such as Operations, portfolio managers,
etc., who find themselves in essentially the same predicament.
Agile201Right out of the box

7. 7
Principle 6: Face-to-face conversations
Principle "The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation."
What does
this mean?
• Traditional (especially waterfall) delivery methods are generally very
document-heavy. Long before a line of code is written, an ocean of ink is
spilt in the form of plans, requirements, specifications, manuals and all the
rest. Some of this documentation is of long-term value, but a lot is there
simply to support the delivery process, and only necessary because the
number of individuals involved is so huge and the lines of communication
so long. This makes most documentation an extremely inefficient method
of communication!
• To make matters worse, the more hand-offs development goes through
(from analysts to designer to coder to testers to user acceptance to
operational acceptance to Operations before working software finally
appears over the horizon, the less likely it is that the result will please
anyone. At least when it is done as badly as it is in many organisations, the
traditional waterfall lifecycle looks remarkably like a game of Chinese
whispers - with similar consequences!
• By working in small, lightweight teams delivering in rapid bursts, the need
for most of this paper and all these hand-offs disappears, to be replaced by
simple, frequent, face-to-face dialogue, rapid decision-making and great
flexibility.
Why is it
hard?
• IT is often thought of in similar terms to a piece of electronic engineering - a
large-scale, complex, technically demanding process. Likewise building
systems is too often thought of as being a bit like building a bridge: it
wouldn't make much sense to build just a little bit of it, or even to start
without a very clear idea of how the whole thing is going to shape up.
• Unfortunately this is just the wrong analogy for software, and for many
other kinds of delivery too (e.g., services). Unless we're aiming for truly
revolutionary change (and probably not even then), we don't have to settle
the Big Picture before we take the first step in building something. Usually
there is something that can be built pretty much straight away that our
users and business groups would welcome.
• So why not just build it? The entire history of IT systems development tells
us that we really don't know how to create a credible Big Picture first
anyway - so why not stop, get together with a small team, and see if there's
another way?
How can we
make it
easier?
• Actually there are quite a few precursors to Agile development and working
face-to-face to solve problems. Many systems are prototyped and roll-outs
start with pilots, whose precise purpose is to use hands-on experience
and face-to-face conversation to feel our way through a mass of
uncertainties.
• As, in fact, an awful lot about systems delivery is inherently uncertain,
promoting Agile as a kind of super-prototyping, super-piloting process is
attractive and uses a language a lot of our stakeholders already
understand.
Agile201Right out of the box

8. 8
Principle 7: Working software
Principle "Working software is the primary measure of progress."
What does
this mean?
• If there is any pair of words that summarise Agile, they are 'working
software'. Not that all software development methodologies aren't
aiming at the same thing, but Agile is unique on keeping the focus on
the end result, and not allowing it to be distracted by formalities such
as contracts, plans, specifications, procedures and status reports.
• The timescales on which Agile operates - most iterations are just 2
weeks in duration - makes this easy to do. After all, delivery is any day
now - quite the opposite of the long-term delivery schedules of so
many traditional delivery projects, where the first delivery might be
the year after next!
Why is it
hard?
• Most people would agree that working software is the primary
measure of success. The problem is not usually the end result, it's
how Agile proposes delivering it.
• Having spent half a century creating larger and larger programmes
with hundreds of participants and managed using bigger and more
complex methodologies, it is pretty counter-intuitive to think that this
could be done better through the series of quick hits Agile calls for.
What many organisations see is not a dramatically superior way of
delivering business value but the latest fad, mainly being offered by
the same IT professionals who have previously not delivered with any
great success!
• In the case of large, radical, complex solutions, it is also not really
clear yet that Agile is itself mature enough to deliver in an efficient
and effective manner. For all the endless emphasis on the scalability
of Agile (through 'scrums of scrums', etc.) and its integration with
conventional management methodologies such as PRINCE2, the
evidence to test the superiority of Agile is not in yet.
• In this situation, most people would agree that working software is
the primary measure of success, but quite a few find it hard to
imagine that jumping straight into removing quite so many familiar
controls and trusting in the professionalism and self-discipline of IT
developers is the way to achieve it.
How can we
make it
easier?
• Agile should be approached in an Agile manner. Bite off small chunks
of work, and make the case for delivering it in a new way. If we can
find a sympathetic business partner, so much the better. Once
we've established that working software is to be had much more
quickly and reasonably than by other means, we can progressively
expand the circle of Agile working practices and teams.
Agile201Right out of the box

9. 9
Principle 8: Sustainable pace
Principle "Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely."
What does
this mean?
• This is essentially an issue of productivity and morale. There is plenty
of evidence showing that a sustainable pace is good for productivity.
It does not mean that we should never rise to a genuine emergency
with more work, but it does mean that, if we make a habit of treating
every problem as a crisis and every milestone as sacrosanct, very
quickly we will start to grind our teams down.
• So, although software projects are notorious for massive overtime as
delivery dates loom, not to mention 'death marches' that seem to go
on forever, the fact is, this approach to delivery is massively counter-
productive. Although more hours can increase the total output for a
while, productivity is much harder to sustain. So after a few weeks it
starts to crash, to the point where the original gains are completely
eaten up the eventual losses.
• From the point of view of morale too, a sustainable pace is an
advantage. If delivery teams are to act as disciplined professionals,
they need to work at tasks they understand and value and which they
believe will contribute to overall success. Merely forcing work upon
them will demotivate them. That is why, in Agile, the whole team are
actively involved in selecting the stories they deliver, take full
responsibility for their own working practices and organisation, and
are expected to understand and contribute to all phases of delivery.
Why is it
hard?
• There is a basic conflict between professionalism and the hierarchical
nature of most organisations. This typically results in professionals
being told what to do, and if they fail to do it, the only remedy is not
to consult them for their professional opinion but to just make them
work harder.
How can we
make it
easier?
• Firstly, we familiarise ourselves with the evidence on using a
sustainable pace to maximise productivity and make sure it is
understood by our senior management and business partners.
• Secondly, set up a pilot project to test the point in our own
organisation. We'll need to be able to measure productivity in an
objective way, which is not easy for many organisations.
• An alternative is to compare the outcomes of two essentially similar
projects - one never working more than a standard working week,
the other subject to all the usual pressures.
Agile201Right out of the box

10. 10
Principle 9: Technical excellence
Principle "Continuous attention to technical excellence and good
design enhances agility."
What does
this mean?
• Technical excellence and good design enhance agility
primarily because they minimise the number of potential
stumbling blocks the team faces with each new story.
• A system that is well conceived, elegantly built and based
on strong concepts (object-orientation, patterns, etc.) is
not just very attractive to engineers; it is also a lot easier
to change.
• So putting effort into the hundreds of small technical
fixes - and mostly they truly are small - is an invaluable
investment for the future.
Why is it
hard?
• Why would anyone ever want anything less than
the best? Unfortunately that's a very easy question to
answer - because the best is a) often not what is actually
needed, and b) very expensive. So simply aiming at
'technical excellence' sounds like a charter for gold-
plating.
• Of course, in Agile it isn't that at all - for example, we
probably wouldn't go out of our way to refactor code
that is rarely used - but it can sound like that, and so turn
off people with no interest in technology and a lot of
interest in budgets and milestones. As these are
generally the more senior people in most organisations,
it will not be obvious to them that this is a sound
objective.
How can we
make it
easier?
• Make clear how often the root cause of defects and
delays is poor engineering, but also that this lack often
follows from the time pressures on teams. Metrics on
technical debt are available but they are not very
specific, so the case will almost certainly have to
be made using local examples or waste and rework
caused by a lack of attention to technical excellence.
Agile201Right out of the box

11. 11
Principle 10: Simplicity
Principle "Simplicity - the art of maximizing the amount of work not
done - is essential."
What does
this mean?
• Simplicity isn't just the art of maximising the amount of
work not done, though that is, obviously, a valuable
achievement. Usually, the simplest way to do something
is not at all, and it is astonishing how many tasks we are
all forced to do that really serve little purpose.
• Simplicity is also organised complexity. That is, by
organising disjointed and poorly thought-through tasks
better, it is also possible to do what really does have to
be done much more quickly, efficiently and reliably.
Why is it
hard?
• In any large organisation, the demand to do certain tasks
can't be altered locally: they're just something we have to
do. Completing a timesheet when the data will never be
used for anything is a case in point: even if everyone
could agree it was a waste of time, the difficulty of
eliminating it would probably be too great and
there probably wouldn't be anyone with the skills or
authority needed to do it.
• Other work is of value to someone and, if they are senior
enough, the fact that the total effort to do it is out of all
proportion to the benefit will generally have no impact.
Often a good example is reporting, which is mandatory
even when many reports are left unread, are not
meaningful and large parts of them have ceased to be
relevant to understanding a project's progress or status.
So each week the same 100-slide deck is generated, even
though only 10 slides are ever read.
How can we
make it
easier?
• Probably the best place to start is with self-organisation.
Once we've demonstrated how simplifying our own
working practices has eliminated any amount of waste
and rework, we'll be in a position to persuade others to
do the same.
Agile201Right out of the box

12. 12
Principle 11: Self-organisation
Principle "The best architectures, requirements, and designs emerge
from self-organising teams."
What does
this mean?
• It has been said that the difference between professionals
and employees is that we pay employees so we can tell
them what to do, while we pay professionals so they will tell
us what to do. It follows that professionals don't need
anyone else to tell them how to do their work.
• But more than that, if we want the highest quality outcome -
architectures, requirements, designs and all the rest - we
have to allow professionals to decide for themselves how
they are going to deliver them. Hence the importance of self-
organisation to Agile teams.
Why is it
hard?
• Although professionals thrive on self-organisation, most of
them work in strictly hierarchical organisations, When the
two come into conflict, the hierarchy almost always wins. It is,
after all, their money.
• At the same time, managers are not generally trained to
encourage autonomy in their teams - quite the opposite - so
there is little likelihood that such an approach will be
welcomed when it is suggested.
How can we
make it
easier?
• The most effective way to prove the value of collaboration is
to actually collaborate, and use the resulting improvements
to persuade the sceptics. Of course, this is a vicious circle, so
what is the way in?
• Fortunately, opportunities to collaborate are extremely
common - both within your team, with other teams, with
users, with SMEs, and so on. If the organisation you work for
limits your ability to collaborate (insists on formal
communications, requires formal meetings to decide the
simplest things, operates rigidly segmented silos, etc.) then
your opportunities are limited.
• However, few organisations are like this nowadays, and even
in such cases it should not be difficult to find like-minded
individuals with whom you can develop collaborative
relationships.
Agile201Right out of the box

13. 13
Principle 12: Reflection
Principle "At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly."
What does
this mean?
• Rather than either rushing blindly ahead with the next piece of
work or relying on someone else to tell you how to improve,
Agile insists that every period of delivery - iteration or release -
should end with a brief reflection on what went well and what
went badly, with the team deciding what needs to change if they
are to do better next time, and then immediately kicking off the
actions needed to make those changes.
• That way, the small problems and mistakes that, in other
methodologies, build up into serious friction, shortcomings,
inefficiencies and even obstacles are eliminated before they
have a chance to derail work, and the bright ideas and
opportunities that are so often lost are really put into action.
• If, on the other hand, we give the team time and space to reflect
and real opportunities and active encouragement to make their
ways of working better, real efficiencies are almost certain to be
discovered, not only by directly improving how the team
operates but also by improving morale - a sure basis for
improving productivity.
Why is it
hard?
• In most organisations the pressure to deliver is extreme,
and the demand that the team should get on with the next task.
Stopping to reflect is not generally regarded as a productive use
of time, and the response to obvious obstacles and
inefficiencies is all too often a simple insistence that the team
should carry on anyway.
• And where teams are encouraged to reflect, the methods used,
such as a typical corporate lessons learned system, are so
poorly designed and implemented that they simply add to
the team's burdens without leading to genuine change.
How can we
make it
easier?
• By adopting key Agile practices we can provide the space to
reflect and improve.
• But even more importantly, these practices prove
the organisation's commitment to supporting the team's
professionalism, and so also create improvements in how the
collaborate and communicate - which creates a virtuous circle
of continuous improvement.
Agile201Right out of the box