Downloaded 58 times
Uploaded byThoughtWorks Studios
ThoughtWorks Approach 2009
The document provides an overview of ThoughtWorks' Agile application development approach. It discusses how most software projects traditionally fail or go over budget and time. It then summarizes key Agile principles like eliminating waste, iterative development, and continuous testing. The document outlines a typical Agile project lifecycle including inception workshops, iterative delivery in releases, and examples of planning tools like burn-down charts. It compares Waterfall and Agile methods and discusses the benefits of Agile in delivering value earlier, improving quality, and lowering the cost of changes.
More Related Content
Similar to ThoughtWorks Approach 2009
ThoughtWorks Approach 2009
- 1. ThoughtWorks Application Development Approach ©ThoughtWorks 2009
- 2. The origin ofAgile concepts
- 3. Software Project Outcomes:2006 65% Over-budget Over-time Under-delivered Failed “The CHAOS Chronicles 2006”, The Standish Group
- 4. Why are theyconsidered failures? Over budget by 189% Over schedule by 220% Only 61% of features are delivered The Standish Group CHAOS Reports
- 5. Waste – majorityof projects are over scoped And the result is ..... waste Always or often used : 20% Always 7% Often 13% Rarely or never used : 64% Sometimes 16% Rarely 19% Never 45% Study by The Standish Group, Jim Johnson Chairman 2002
- 6. Reducing Waste isthe Single Biggest Opportunity For Cost Reduction Waste in requirements capture Scope Functional and Technical scope not needed Minimised Cost Cost to build Waste in defect correction
- 7. Agile/Lean Principles • EliminateWaste • Develop iteratively/Release often – Realise business value earlier – Allow for regular reprioritisation • Test continuously (and earlier in the process) • Create visibility and maximise feedback – Between Business and IT – Business IT management and development teams – Within teams
- 8. A typical Agileproject lifecycle
- 9. Inception Phase ofan Agile project QuickStart workshops
- 10. QuickStart: Agile RequirementsGathering Time Boxed Pre-meet Final Showcase Weekly Showcases 2 – 4 Weeks © ThoughtWorks 2008
- 11. QuickStart: Collaborative andInclusive © ThoughtWorks 2008
- 12. Clear communication isthe foundation “I’m glad we’re all agreed then.”
- 13. Get those mentalmodels out on the table “Ah...”
- 14. An explicit model allowsconvergence through iteration “Ah!”
- 15. A genuinely sharedunderstanding “I’m glad we’re all agreed then.”
- 16. Outputs of QuickStartworkshops
- 17. Potential outputs • • • • • • • Prioritised businessobjectives Business vision Roadmap Architecture model Low fidelity prototypes / prototypes Prioritised estimated master requirements list High level release plan
- 18. The master requirementslist • Master requirements list – – It collects the output of the analysis as requirements (units of value) These requirements are qualified by risks, issues, assumptions, dependencies and constraints • For each requirement: – – The business has an understanding of its business value Those implementing the requirement (e.g. IT) have an understanding of the required effort (an estimate) • The business then prioritises based on: – – – The estimate Their knowledge of the business value Input from those implementing the requirement, e.g. IT (dependencies, end-to-end slice)
- 19. High level releaseplan • The estimated and prioritised master requirements list provides an excellent foundation for the creation of the high level release plan • In turn this gives preliminary answers to important planning questions, e.g. – – – – Number of releases Content of those releases Sequencing / dependencies Duration • All of which position the business to make the required decisions about implementation
- 20.
- 21. Example of ReleaseCycle – as executed at clients 50% through Itr 2 Itr 3 Itr . Release Test Release Itr 1 80% through Test Release Production Candidate Itr . Itr . Itr . Itr . Itr . Itr n Deploy End to End process review in every iteration Solution Architecture evolves ongoing through all iterations Ongoing testing: Unit Testing, Acceptance Testing, System Testing, Exploratory Testing, Performance Profiling Show case Show case Show case Show case Show case Show case Show case Show case Show case Show case UAT UAT UAT Performance , Security and Operations Testing Performance , Security and Operations Testing Performance, Security and Operations Testing System Integration Test System Integration Test System Integration Test Regression Test Regression Test Regression Test
- 22. Test earlier andcontinuously
- 23. Agile Practices • • • • Test DrivenDevelopment (TDD) Automated testing Continuous integration Spikes (fast, time-boxed evaluation of technical approach – Fail Fast) • Refactoring • Low-fi prototyping • Automated deployment
- 24. Measuring Progress –Burn Charts Used to Show – Total Scope and any changes over time (scope creep) – Completed Scope (completed means tested, production quality software) – Scope remaining to be completed – Helps drive decisions – scope Vs budget Vs time Project Burn Up Chart 300 250 Points • 200 150 100 50 0 1 2 3 4 5 6 7 8 9 Iteration Start Scope Current Scope Complete Planned Burn
- 25. Burn-up chart 180 160 140 120 Original Scope 100 ActualScope 80 Actual Points 60 Predicted Velocity 40 20 0 1 2 3 4 5 6 7 8 9 10
- 26. Example: One ClickShowcase Pr oj ect Tr acki ng Ti m i ne – R ease 1 el el 20/ 08 15/ 10 W ar e her e. e I t er at i on 0 I t er at i on 1 I t er at i on 2 I t er at i on 3+4 ( com ned) bi I t er at i on 5+6 ( t est & depl oy) % C pl et e – R ease 1 om el I‟ n 1 – 34pt s 0% 0 55 pt s ( 49% ) W ar e her e e © ThoughtWorks 2008 100% 212 pt s
- 27. Waterfall compared withAgile Project Plan/Estimation Requirements Gathering Use Cases / Functional Specs Design Specifications Code Inception Test Release 1 $ Release 2 • Short Iterations • Frequent Releases • Earlier ROI Fix / Integrate $ $ Release 3 $ Release 4 $
- 28. Lower cost ofchange through higher quality software Cost of change curve Agile system cost profile
- 29. Benefits of Agile • • • • • • • • Deliversbusiness value early, and often Faster time to market Maximises return on investment (business value prioritised) Encourages higher quality, simpler code (lower maintenance costs) Better Business-IT alignment Increases visibility into project progress and reduces risk Handles changing requirements and priorities Lowers cost of change
- 30. Discipline in anAgile project
- 31. Rigour in theAgile methodology (1) • To be able to deliver effectively in an Agile project, much more discipline is required than in traditional projects. The constant feedback and transparency give the business on-going control and a mechanism to make and change decisions from beginning to end of the project. Surprises late in the project are prevented. • Part of the Initiation phase are QuickStart workshops which provide: – – – – – – Input for Business Case Release Plan Estimates Technical vision Architecture Design Test Strategy
- 32. Rigour in theAgile methodology (2) • The Solution Architecture is developed and reviewed on-going through the iterations. • Each iteration delivers a showcase which provides the business and stakeholders with a sign-off point on progress regarding scope, time and budget. • Documentation is produced on the „just enough‟ principle making it efficient and effective by ensuring that what is produced will be used, thereby reducing waste. The documentation deliverables are adapted to the clients requirements.
- 33. Traditional vs Agileplanning With any kind of planning – A little effort helps a lot (80/20 rule). – A lot more effort only helps a little. • Traditional Planning: Spend a lot of time upfront and understand the problem in detail to come up with an “accurate” plan. Agile Planning: – Spend just enough time upfront to get started and plan to change as the project travels. – Do just enough to enable effective decision making, covering: • Business case • Requirements • Architecture • Design – Review these artefacts on an ongoing basis at iteration checkpoints. Goal of agile planning is to establish a process that embraces changing the plan by making change easy to manage. • • Accuracy • Effort
- 34. When do weplan? Stories QuickStart 1 2 … n 1 Release 1 Initial Planning 2 … Release N m Iterations Releases Constant Planning and Re-Planning 34
- 35. Why ThoughtWorks? ThoughtWorks is •A thought leader in application development • A world leader in the application of Agile practices ThoughtWorks delivers the best value for money through • Short time to benefit / market • The ability to adapt to changing requirements continuously • Minimising risk