The Agile Manifesto (and a brief history lesson)
- 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. 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. 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.
- 11. Values
Principles
Crystal XP
ASD DSDM
FDD Scrum Your Process
Editor's Notes
- 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 :-)