What Is Agile? (10 Key Principles of Agile)

What is agile?  Agile is one of the big buzzwords of the IT development industry. But exactly what is agile development?

Put simply, agile development is a different way of managing IT development teams and projects.

The use of the word agile in this context derives from the agile manifesto.  A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way.  They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then.  It says, “we 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.”

Ever since then, the use of methods that support these values has become increasingly popular.

From my use of various agile methods, I have written about 10 key principles of agile.  These are characteristics that are common to all agile methods, and the things that I think make agile fundamentally different to a more traditional waterfall approach to software development.  They are:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

There are various methodologies that are collectively known as agile, as they promote the values of the agile manifesto and they are consistent with the above principles.  The most popular ones are:

DSDM is probably the original agile development method. DSDM was around before the term ‘agile’ was even invented, but is absolutely based on all the principles we’ve come to know as agile.  DSDM seems to be much less well-known outside of the UK.

Scrum is also an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.  Scrum is the most popular and widely adopted agile method – I think because it is relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades.

XP (Extreme Programming) is a more radical agile methodology, focusing more on the software engineering process and addressing the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product.

DSDM is probably the most complete agile methodology, whereas Scrum and XP are easier to implement and complementary because they tackle different aspects of software development projects and are both founded on very similar concepts.

Over the last 10 years, there is an ever-increasing volume of success stories, where companies have dramatically improved the success and performance of their IT development teams and projects.  This has caused agile to be widely adopted across a variety of industries, including media and technology, large corporates, and even government.

In reality, though, agile is not a magic bullet for all software development issues.  The real trick is to know lots of techniques from various waterfall and agile development methods, and to select a mixture of the best approaches that are most appropriate for any given situation.  To do this reliably with any degree of success really requires a lot of experience and skill.

In agile software projects, project management takes a slightly different form, relying far more on the project manager’s skills in communication, facilitation, coordination, and emphasising far less on planning and control.

Agile development can be a very exciting and invigorating approach, although some projects suit agile more than others.  The collaboration and visibility can provide a much richer and more rewarding experience for teams to develop great software products. Agile development can be a lot more enjoyable than the waterfall approach, which requires lots more documentation and is less flexible by its nature. And when people enjoy their work, it’s amazing what they can achieve!


See also:
10 Key Principles – PowerPoint Presentation

33 Responses to “What Is Agile? (10 Key Principles of Agile)”

  1. Paul Klipp says:

    Welcome to agile blogging. Don’t be discouraged if you don’t get a flood of readers for a while. The community needs as many voices as it can get.

    Paul Klipp

  2. Anonymous says:

    Would you say that maybe one approach to testing is defining how to test the results of what is produced in a sprint before work is done in the sprint?

    I am producing code to read data from a database then display it on a form. Should I wait until i’m done or would it be prudent to define the tests for the fields and such before I start?

    Personally I like to define how I am going to test what I am working on rather than develop a test case or plug in unit testing after the fact.

    What do you think?


  3. Anonymous says:

    8% of the functionality of MS Word?

    Isn’t that called Word Pad? Does that mean that Microsoft already considered your argunment?

    I did notice a few typos with some of the 10 Principles text… perhaps some of the other 92% of MS Word should have been utilised?

  4. Kelly Waters says:

    Hi anonymous,

    Many thanks for the feedback.

    I didn’t mean to imply that Microsoft hadn’t considered the 8% thing, i.e. that most people don’t use most of the features. I’m sure they did. And WordPad may well be the evidence of that.

    I was just trying to highlight that software teams should proactively consider that fact too. And that maybe this is the basis for a strategy for the earlier iterations of a product’s development – business people may say that the product needs all the features – and they may be right. But general evidence is that products do not need to be that rich in functionality to attract the majority of its users.

    Thanks for the feedback about the typos in my blog posts! I use Google’s Blogger platform to write my blog, which unfortunately has less than 8% of Word – perhaps even as little as 1%, and sadly not a spell check!!! I’ll go fix my typos :-)


  5. Karthiganesh says:

    Hi Kelly,

    It is really good work. I am employing Agile Development Model for my current project. Earlier I employed RAD and Waterfall. But current situation makes me use Agile Development. Initially I am reluctant to accept that I am using Agile Development Model, as I did not know much about this. After reading your Blog, I can affirm that I am using this.

    I found this blog is useful.

    I will post my comments regularly.


  6. Kelly Waters says:

    Hi Karthiganesh

    Many thanks for your comment, it’s really great to get such positive feedback.

    Kind regards


  7. Anonymous says:

    First of all I like your top ten and agree that they are all important principles. Unfortunately I miss a common vision in the top five to drive development. I find that a common vision is a great practice to align business and IT, both when things are going “according to plan” and especially when they don’t.

    Check out my own top 6 on http://www.agilethoughts.dk – we pretty much agree on the other 5 ;-)


  8. Kelly Waters says:

    Hi anonymous,

    Many thanks for the feedback…

    Shared Vision is of course a very important principle of any project, whether it’s agile or not.

    I wouldn’t include it in my key principles of agile, simply because I don’t think it’s a differentiator. Traditional development methods emphasise vision as much as agile methods.

    Anyway, 11 key principles doesn’t have quite the same ring to it :-)


  9. Mark says:

    I believe an important aspect of Agile is not only releasing what is functionaly requested by the user base and generating revenue for features/product that people want to buy vs. features no longer wanted, but usability has to come into play as well. If you deliver working software without the desired usability, you still haven’t succeeded.

    I would also recommend reading Damon Poole’s blog from Accurev. Some very insightful and regular posts that we find valuable.


  10. Project Management Templates says:

    Thanks for this informative post

  11. Project Management Software says:

    It really great to participate in conversation. i got the information from happening discussion here.


  12. Anonymous says:

    Thanks Kelly,
    This is one of the best Agile's blogs I have ever come across.
    It is simple and clear in expalining Agile methodology.


  13. Kelly Waters says:

    Thanks Ahmed, that's really nice of you to take the time to say that.


  14. Elizabeth says:

    Hi Kelly, This blog is great. Thanks for all your work. I am writing a book on Agile — can I quote you in it? You'd make a wonderful expert for it.

  15. Elaine says:

    Hi Kelly,

    I hope you can help me in my research for my master degree. I am trying to find out where the term Agile working came from and how it evolved.

    I am trying to see if it is practical to make the back office employees in a finance company ‘Agile’, and how Agile could inpact on motivation and goverment directives.


  16. Andrej says:

    great list. i always have one more item in mind for myself.
    “It’s important what you are doing, but not how you are doing”

  17. Hello Kelly

    Nice blog you made here, I got a website about the waterfall Model and also about agile software development. I hope I can call your name here and there.. since you provided me with some really usefull information about agile.

  18. Casey says:

    Great post. I know I’m late to the post, but just diving into SCRUM and whatnot. Definitely a lot to learn, but so valuable. Thanks.

  19. Bharath Seshadri says:

    Just spare 2 minutes to think that building a software is like constructing a home.
    1. You can construct a home without a blueprint.. It will definitely be built…. but if some one else purchases the house tomorrow will he know the wiring, strengths and weakness of the house.
    2. Will the new comer know the security advantages and restrictions of the house or should it remain an assumption.
    3. Tomorrow if somebody wants to add a new room in a new floor wouldn’t it help to have a blue print of the house or does he have to study the house or just break the house and start allover again because he does not know the wiring details etc
    4. Houses if properly planned can be built to even be earth quake resistant as they are now present in earth quake prone regions after a previous earth quake.
    5. Watch the news and serials where day in and day out buildings are collapsing or roof is falling or there are water leakages, all due to poor construction work.

    In short Waterfall model is one extreme and Agile is another extreme. We need to strive to achieve the perfect results of a waterfall model while using the pace and speed of an agile model. Try to think of the two models as a weighing balance where the product is stable only if the weights are equal.

    1.Just because a region has frequent earth quakes, it is wrong to infer that we do not require a blue print for constructing the house and changing the blueprint as and when new additions are made. On similar terms just because the requirements are changing it is wrong to conclude that changing requirements should not be recorded in a formal approach.
    2. We need to aim at Earth Quake resistant houses that have good blue prints and with good explanation of all its whereabouts such as security features, positives and negatives that are not assumed but are explicitly stated. Similarly we need software that are robust and have all requirements captured and that have well documented artifacts that don’t make room for assumptions.

  20. James says:

    Hi Kelly,

    Awesome blog you got here. Really helped me through my studies on agile development.

    Thanks alot!

  21. Tushar says:

    Hi Kelly,

    I resonate with you when you said “what is agile” is one of the most searched question and the count is going up.

    For me, agile is not agile manifesto or different methodologies like scrum, XP etc… Agile is much more and beyond values, manifesto, principles and methodologies. It is much much deeper than all of these.

    This is what I explained in my blog post


    Edited version of the post also features on ScrumAlliance.org at


    What is agile? The Free Dictionary defines it as “characterized by quickness, lightness, and ease of movement.” Webster notes that it is “marked by ready ability to move with quick, easy grace.” The way I like to put it is, “Quickly responding to changes defines agility.”

    In the context of software development, how quickly, lightly, easily, readily, and gracefully we respond to changes while developing software defines our agility. (Notice the word respond and not react.)

    Hope this helps and adds value.

    Can I have this post of yours on my site too?
    Would you like to write a guest post exclusive for me?

    Thanks in advance and best of luck for all you do.

    Tushar Somaiya.
    Agile Coach, Results Certified Coach & Servant Leader

  22. Mehmet Seker says:

    I totally agree with you on mixing up useful part of the other methodologies that fits your project better instead of confining into a single methodology.

  23. Thanks for the nice and detailed article, my favorite part is “A collaborative & cooperative approach between all stakeholders is essential”

    It takes ages to come to a collaboration and cooperation approach, specially when people are used to work in their own silos.

  24. Suni Jain says:

    A perfect and most basic article for agile. I studied it from starting to end and got basic knowledge about agile.

  25. Steve Shields says:

    I have read several articles that advocate that the ‘Agile’ Team would be required to be co-located, but surely with modern technology etc and the fact IT suppliers are not always in-house that this is not a pre-requisite?

  26. Varaprasad says:

    Hi Kelly,

    Nice Article. Given clear high level idea on Agile principles. 10 principles are articulated in very understanding manner. I have worked for 2 major development projects. Initial one have lot of issues due to larger single release with lot of requirments and time duration(More than 2 years). Knowingly or Unknowingly, we follow the most of these Agile principles in the 2nd project and able to deliver multiple modules in iterative manner and able to release timlely deliverables and able to make customer happy.


  27. achi says:

    thank you s much kelly :) :) :)

  28. john says:

    After reading this I still don’t understand Agile (or XP or Scrum).

    Aren’t the 10 characteristics part of every project planning model? What are the success stories?

    Isn’t agile all about: a chaotic, developemnt approach steered by customer’s changing demands but whithout documentating?

  29. Brian says:

    Hi John,

    In a traditional software development, you would typically have a requirements gathering phase (analysts plus business stakeholders), design (analysts plus architects or senior developers), coding (development team), testing (developers plus QA), then user acceptance testing, before sign off and release. The key thing to note here is that each part of the process happens only once.
    In this model stakeholders are involved at the start and at the end only – this can be months or even years apart – this is considered to be not “active” by the OP. Equally, they only see one “release” and therefore get no chance to steer the software if it is not what they require. The assumptions in waterfall projects that allow a detailed plan to be produced are that the customer knows what they want and that it will not change during the lifetime of the project. Experience suggests this not to be the case.

    On your final point, agile software development favours working software that delivers value over documentation. However, if documentation is the most valuable item your team could produce at a given time then that us what they *should be* producing. Agile development does NOT equate to undocumented development

  30. Frank says:

    In a traditional software development, you would typically have a requirements gathering phase (analysts plus business stakeholders), design (analysts plus architects or senior developers), coding (development team), testing (developers plus QA), then user acceptance testing, before sign off and release. –

    Your previous explanation is good for the traditional method. What will be different if Agile method is used for the same software development description above from your blog. Am so confuse about the difference. Thanks

  31. Kate says:

    We’re Building a Planning Poker Tool That’ll Make You Flip, and We Need Your Feedback

    Hey there. You’re familiar with Agile, right? Of course you are. Well, then you’re also familiar with the one meeting that you have to have and that you absolutely dread.

    Yeah, we’re talking about sprint planning. Long, tedious, boring and seemingly never-ending. We’ve all been there: the epic user story with a zillion details, the one story that is either 5 effort points or 100 (let’s discuss that!), or the lunch order discussion that somehow takes up half the morning.

    Well, we’re making a tool to make that all better, and we’d like your help to make it better. We’re calling it Poplr (learn more at http://www.poplr.io), and we’re really excited about what it will help Agile teams to do.

    Here are some features we’re already including in our beta (coming this weekend), but we want to know what else you’d love for us to include:

    Unique, shareable poker games for your team; a dealer role to create a game and track results; story point averaging; annotation tools and team chat; a timer to avoid tangents; and the big one – the ability to export to .CSV!

    This sounds amazing, right? Right. But we think it can be better if we have your help.

    Let us know what type of features you’d like to see in an agile planning poker app. Tell us about some problems you’ve been having in your poker sessions. We’ll let you know when we’re going live (beta coming later this week)!

    Check us out at http://www.Poplr.io, and hit the Feedback button!

    Thanks in advance for your feedback. Happy sprint planning!

  32. Sanket says:

    Agile is the most worst methodology in IT industry.

    It treats human as a machine. It over pressurises all participants (Developer and tester) throughout the project and does not guarantee quality of the product.
    I have seen many of colleague leaving companies who are trying to implement agile methodology agreessively.
    In an enterprise project, being a complex project, most of the people failes to estimate tasks and they starts lagging behind the schedule.

    Due to this they either stay long hours in company or works on weekend.

    These poor guys spends there most of the life in AC cabins, they loses there connections with outside people and family members.

    Due to this they won’t able to work for a longer period of time and this results in major health issues, depression and thereby they become jobless.

    Agile doesn’t give work and life balance.

    IT guys should come up with some best methodology which will fall between waterfall and agile.

  33. P says:

    I’m a Business Analyst and new to AGILE. Our company is looking at moving towards AGILE. My question is in the AGILE environment is how has the role of the BA change?

Leave a Reply

What is 1 + 7 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)