Your SlideShare is downloading. ×
Agile Manifesto
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Agile Manifesto

1,518
views

Published on

Presentation given at Ignite Web (Melbourne) in April 09 about the Manifesto for Agile Software Development.

Presentation given at Ignite Web (Melbourne) in April 09 about the Manifesto for Agile Software Development.

Published in: Technology, Business

1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
1,518
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
41
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • “Manifesto for Agile Software Development”



    better way of building software


  • 17 middle aged white guys



    1. Martin Fowler (Chief Scientist TW) * Kent Beck (JUnit, TDD, XP) * Alistair Cockburn * Ward Cunningham (invented Wiki) * Andrew Hunt * Dave Thomas (PragProg) * Robert C. Martin
    2. Mike Beedle * Arie van Bennekum * James Grenning * Jim Highsmith * Ron Jeffries * Jon Kern * Brian Marick * Steve Mellor (UML, IEEE Software mag) * Ken Schwaber * Jeff Sutherland





  • * I’m talking about the principles
    principles - big hitters




  • while there is value in the items on the bottom, we value the items on the top more



    something funny!


  • story:
    - dev and testing in two groups - process build and test
    - blame as people used the process to identify ‘issues’
    - things went bad and added more process
    - two groups brought closer together and removed barriers - one team - emphathy
    - horizontal groups


  • * you need both processes and tools. they help. but dont be a slave.



    story:
    - dev and testing in two groups - process build and test
    - blame as people used the process to identify ‘issues’
    - things went bad and added more process
    - two groups brought closer together and removed barriers - one team - emphathy
    - horizontal groups


  • * let good people do what you hired them to do. make a decision!



    story:
    - dev and testing in two groups - process build and test
    - blame as people used the process to identify ‘issues’
    - things went bad and added more process
    - two groups brought closer together and removed barriers - one team - emphathy
    - horizontal groups



    good: lean & adaptive processes and tools - like svn, git, simple pm, simple forecasting - back off MBAs!





  • story: At a startup where they wrote a word doc for every page
    - know what is in the system
    - just use the system


  • * agile does _NOT_ say ‘no doc’, Lean says ‘just enough’ doc



    story: At a startup where they wrote a word doc for every page
    - know what is in the system
    - just use the system


  • * agile does _NOT_ say ‘no doc’, Lean says ‘just enough’ doc



    story: At a startup where they wrote a word doc for every page
    - know what is in the system
    - just use the system



    you need some doc - it is a form of comms, but don’t do it at the expense of face-to-face.
  • Talk about last massive project
    * kept squeezing each task into smaller and smaller timeframe
    * scheduled to work at 12 midnight and 4am
    * gung-ho attitude of push it through so you don’t look like a ‘failure’
    * had to change the plan when we ran late.



    Edward Yourdon - Death March
    * budget, timeline, morale is blown and you keep on going



    only helps contracting companies - not client, not employees, not contractors





  • Talk about last massive project
    * kept squeezing each task into smaller and smaller timeframe
    * scheduled to work at 12 midnight and 4am
    * gung-ho attitude of push it through so you don’t look like a ‘failure’
    * had to change the plan when we ran late.



    Edward Yourdon - Death March
    * budget, timeline, morale is blown and you keep on going



    only helps contracting companies - not client, not employees, not contractors





  • Talk about last massive project
    * kept squeezing each task into smaller and smaller timeframe
    * scheduled to work at 12 midnight and 4am
    * gung-ho attitude of push it through so you don’t look like a ‘failure’
    * had to change the plan when we ran late.



    Edward Yourdon - Death March
    * budget, timeline, morale is blown and you keep on going



    only helps contracting companies - not client, not employees, not contractors





  • Hardest point
    * most contracts define deliverables and in an agile project these change
    * get the lawyers in last
    grant the vendor a financial incentive if the project objectives are achieved -- and a penalty if they aren't - these goals are business objectives rather than technical objectives
    * just enough formality to make agreements safe for both sides



    http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmu0617.html
  • Hardest point
    * most contracts define deliverables and in an agile project these change
    * get the lawyers in last
    grant the vendor a financial incentive if the project objectives are achieved -- and a penalty if they aren't - these goals are business objectives rather than technical objectives
    * just enough formality to make agreements safe for both sides








    http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmu0617.html


  • Hardest point
    * most contracts define deliverables and in an agile project these change
    * get the lawyers in last
    grant the vendor a financial incentive if the project objectives are achieved -- and a penalty if they aren't - these goals are business objectives rather than technical objectives
    * just enough formality to make agreements safe for both sides






    http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmu0617.html
  • * 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.
    * Business people and developers must work together daily throughout the project.



    **teaser! Find out more


  • - hopefully nothing to crazy in there.
    - this is what agile is supposed to be about
    - ignore the cowboys and learn for yourself!
  • Tool that captures these values
    Alpha
    Need interested people to help make something great
  • Transcript

    • 1. Agile Manifesto what? changingplan.com
    • 2. Agile Manifesto who? changingplan.com
    • 3. 4 values & 12 principles changingplan.com
    • 4. Scrum XP FDD Pragmatic changingplan.com
    • 5. great stuff good stuff changingplan.com
    • 6. individuals & interactions processes & tools changingplan.com
    • 7. processes & tools changingplan.com
    • 8. individuals & interactions changingplan.com
    • 9. working software comprehensi ve changingplan.com
    • 10. omprehensiv e ocumentatio n changingplan.com
    • 11. working software changingplan.com
    • 12. responding to change following a plan changingplan.com
    • 13. following a plan changingplan.com
    • 14. responding to change changingplan.com
    • 15. customer collaboration contract negotiation changingplan.com
    • 16. contract negotiation changingplan.com
    • 17. customer collaboratio n changingplan.com
    • 18. 12 principles changingplan.com
    • 19. agilemanifesto.org changingplan.com
    • 20. changingplan.com Thanks: Agile Software Development Manifesto http://www.colourlovers.com/palette/725464/real_life changingplan.com