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.

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