0
The Agile Manifesto
   (and a bit of a history lesson)
Agile isn’t new
Agile isn’t new
Manifesto Values
We are uncovering better ways of developing software by
doing it and helping others do it. Through this w...
Manifesto Principles
Our highest priority is to satisfy the customer        Working software is the primary measure of
thr...
Manifesto Values
We are uncovering better ways of developing software by
doing it and helping others do it. Through this w...
Individuals and interactions
 over processes and tools
Working software over
comprehensive documentation
Customer collaboration over
    contract negotiation
Responding to change over
     following a plan
Values



           Principles

Crystal         XP
          ASD           DSDM
FDD          Scrum      Your Process
Scrum = Agile
Scrum ≠ Agile
agilemanifesto.org
You should ask
questions now :-)
        adrianh@quietstars.com
             twitter.com/adrianh
                  quietst...
Upcoming SlideShare
Loading in...5
×

The Agile Manifesto (and a brief history lesson)

1,790

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,790
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
40
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • First the history lesson...
  • * You can find examples of some “agile” practices in the 50s/60s.
    * Scrum has its origins in mid-80s, formalised in the mid-nineties.
    * Extreme Programming started mid-nineties.
    * All before the term “Agile” was ever used.
  • * What XP, Scrum, etc. did was bring together practices in a new way
    * Synergy between practices. Sum is greater than its parts.
    * Previous common term was “lightweight” - obvious double meaning.
    * “Agile” as a term to describe these terms dates from Feb 2001.
    * Group of 17 practitioners got together and produced...

  • Break the rules - and read out the slide.
  • * There are also principles... but we only have ten minutes.
    * But you should really go read them and think about them.
    * I’ll give a pointer at the end for those who are interested.
  • * This bit is important.
    * Agile is not rejecting process, tools, documentation, contracts and plans.
    * Agile is about changing the priorities.
    * Everything subservient to the things that produce working software providing business value
    * Let’s talk about these in a bit more detail
  • * Not about just sitting down without a plan and hacking.
    * Not about absence of tools (e.g. xUnit frameworks, index cards)
    * Not about absence of process (e.g. stand ups, planning game)
    * It’s stopping processes and tools getting in the way of people building the product. Personal networks and communication vital.
    * It’s focussing on the _people_ and making them more effective
    * E.g. Adopting TDD frees up testers for Exploratory Testing
  • * We’re all familiar with the evil 3 inch requirements documents with the 27 8-by-10 colour glossy photographs with circles and arrows and a paragraph on the back of each one.
    * It’s always wrong. Hard to see where.
    * By focusing on iteratively delivering software - we avoid the problem
    * Document to communicate - not to define.
    * Draw maps, not plans.
  • * Traditional processes are usually contractual.
    * “We want this” / “We can do this”
    * When this changes - trouble ensues.
    * “this” often changes
    * Agile process are collaborative and consensus driven
    * “We’re producing this”
  • * The plan, as they say, never survives contact with the enemy
    * Q: When do management and customers want to know about problems?
    * A: Now
    * Traditional processes are fragile in the face of changing requirements
    * Build your processes around feedback and change.
    * “Embrace change” was one of the XP slogans
    * Maps. Not plans.

  • * So we have a bunch of effective processes…
    * That share some common principles…
    * … and common values
    * Agile is empirical
    * Based on working methods, not academic business theory
    * Agile is not a silver bullet
  • * Some treat Scrum and Agile as synonyms.
  • * Not true.
    * Scrum is one of family of methods - including XP, FDD, etc.
    * They all share values and principles of the Agile Manifesto
    * If your process is failing - it pays to revisit the values & principles
  • * Read all the values and principles here
    * It’s worth spending the time
    * Look at _other_ agile methods than the one you use
    * Look for practices from other fields, like UX, that share agile values

  • * If you have any questions... just drop me a line :-)

  • Transcript of "The Agile Manifesto (and a brief history lesson)"

    1. 1. The Agile Manifesto (and a bit of a history lesson)
    2. 2. Agile isn’t new
    3. 3. Agile isn’t new
    4. 4. Manifesto Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
    5. 5. Manifesto Principles Our highest priority is to satisfy the customer Working software is the primary measure of through early and continuous delivery of valuable progress. software. Agile processes promote sustainable development. Welcome changing requirements, even late in The sponsors, developers, and users should be able development. Agile processes harness change for the to maintain a constant pace indefinitely. customer's competitive advantage. Continuous attention to technical excellence and Deliver working software frequently, from a couple good design enhances agility. of weeks to a couple of months, with a preference to the shorter timescale. Simplicity — the art of maximizing the amount of work not done--is essential. Business people and developers must work together daily throughout the project. The best architectures, requirements, and designs emerge from self-organizing teams. Build projects around motivated individuals. Give them the environment and support they need, and At regular intervals, the team reflects on how to trust them to get the job done. become more effective, then tunes and adjusts its behavior accordingly. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    6. 6. Manifesto Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
    7. 7. Individuals and interactions over processes and tools
    8. 8. Working software over comprehensive documentation
    9. 9. Customer collaboration over contract negotiation
    10. 10. Responding to change over following a plan
    11. 11. Values Principles Crystal XP ASD DSDM FDD Scrum Your Process
    12. 12. Scrum = Agile
    13. 13. Scrum ≠ Agile
    14. 14. agilemanifesto.org
    15. 15. You should ask questions now :-) adrianh@quietstars.com twitter.com/adrianh quietstars.com
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×