Your SlideShare is downloading. ×
ThoughtWorks Approach 2009
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

ThoughtWorks Approach 2009

245

Published on

Introduction to ThoughtWorks' Application Development Approach

Introduction to ThoughtWorks' Application Development Approach

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
245
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
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

Transcript

  • 1. ThoughtWorks Application Development Approach © ThoughtWorks 2009
  • 2. The origin of Agile concepts
  • 3. Software Project Outcomes: 2006 65% Over-budget Over-time Under-delivered Failed “The CHAOS Chronicles 2006”, The Standish Group
  • 4. Why are they considered failures? Over budget by 189% Over schedule by 220% Only 61% of features are delivered The Standish Group CHAOS Reports
  • 5. Waste – majority of 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 is the 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 • Eliminate Waste • 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 Agile project lifecycle
  • 9. Inception Phase of an Agile project QuickStart workshops
  • 10. QuickStart: Agile Requirements Gathering Time Boxed Pre-meet Final Showcase Weekly Showcases 2 – 4 Weeks © ThoughtWorks 2008
  • 11. QuickStart: Collaborative and Inclusive © ThoughtWorks 2008
  • 12. Clear communication is the foundation “I’m glad we’re all agreed then.”
  • 13. Get those mental models out on the table “Ah...”
  • 14. An explicit model allows convergence through iteration “Ah!”
  • 15. A genuinely shared understanding “I’m glad we’re all agreed then.”
  • 16. Outputs of QuickStart workshops
  • 17. Potential outputs • • • • • • • Prioritised business objectives Business vision Roadmap Architecture model Low fidelity prototypes / prototypes Prioritised estimated master requirements list High level release plan
  • 18. The master requirements list • 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 release plan • 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. Delivery Phase
  • 21. Example of Release Cycle – 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 and continuously
  • 23. Agile Practices • • • • Test Driven Development (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 Actual Scope 80 Actual Points 60 Predicted Velocity 40 20 0 1 2 3 4 5 6 7 8 9 10
  • 26. Example: One Click Showcase 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 with Agile 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 of change through higher quality software Cost of change curve Agile system cost profile
  • 29. Benefits of Agile • • • • • • • • Delivers business 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 an Agile project
  • 31. Rigour in the Agile 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 the Agile 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 Agile planning 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 we plan? 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

×