The 12 Agile Principles

Overview and explanation of the 12 Principles contained in the Agile Manifesto.

For more - and a complete implementation of Agile for $1.90 - go to Agile201.com.

1. The 12 Agile Principles From the Agile Manifesto’s 4 basic statements, 12 foundational principles were derived. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity - the art of maximizing the amount of work not done - is essential. The best architectures, requirements, and designs emerge from self-organizing teams. 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? Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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! Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box

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. Agile 201 Right out of the box