ThoughtWorks Approach 2009

transcript

ThoughtWorks Application Development Approach

The origin of Agile concepts

Software Project Outcomes: 2006

65% Over-budgetOver-time

Under-delivered

Failed

“The CHAOS Chronicles 2006”, The Standish Group

Why are they considered failures?

Over budget by 189%Over schedule by 220%

Only 61% of features are delivered

The Standish Group CHAOS Reports

Waste – majority of projects are over scoped

Study by The Standish Group, Jim Johnson Chairman 2002

Sometimes16%

Rarely19%

Always7%

Often13%

Never 45%

Always or often used : 20%

Rarely or never used : 64%

And the result is ..... waste

Reducing Waste is the Single Biggest Opportunity For Cost Reduction

Cost to build

Functional and Technical scope not needed

Waste in requirements

capture

Waste in defect

correction

Minimised Cost

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

A typical Agile project lifecycle

Inception Phase of an Agile project

QuickStart workshops

QuickStart: Agile Requirements Gathering

Pre-meetFinal Showcase

Time Boxed

2 – 4 Weeks

Weekly Showcases

QuickStart: Collaborative and Inclusive

Clear communication is the foundation

“I’m glad we’re all agreed then.”

Get those mental models out on the table

“Ah...”

An explicitmodel allows convergence through iteration

“Ah!”

A genuinely shared understanding

“I’m glad we’re all agreed then.”

Outputs of QuickStart workshops

Potential outputs

• Prioritised business objectives• Business vision• Roadmap • Architecture model• Low fidelity prototypes / prototypes• Prioritised estimated master requirements list• High level release plan

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)

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

Delivery Phase

Example of Release Cycle – as executed at clients

Ongoing testing: Unit Testing, Acceptance Testing, System Testing, Exploratory Testing, Performance Profiling Ongoing testing: Unit Testing, Acceptance Testing, System Testing, Exploratory Testing, Performance Profiling

Performance, Security and Operations Testing

System Integration Test

Regression Test

UATUAT

Release

Production Candidate

Release

Production Candidate

50% through

Test Release

50% through

Test Release80% through

Test Release

80% through

Test Release

Itr 2 Itr 3 Itr . Itr . Itr . Itr . Itr . Itr . Itr n Deploy

Regression Test

Showcase

UATUAT UATUAT

Performance, Security and Operations Testing

Solution Architecture evolves ongoing through all iterationsSolution Architecture evolves ongoing through all iterations

End to End process review in every iteration End to End process review in every iteration

Test earlier and continuously

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

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

1 2 3 4 5 6 7 8 9

Iteration

Start Scope Current Scope Complete Planned Burn

Burn-up chart

1 2 3 4 5 6 7 8 9 10

Original Scope

Actual Scope

Actual Points

Predicted Velocity

Example: One Click Showcase

Ti mel i ne – Rel ease 1

We are here.

15/ 1020/ 08

Iterati on 3+4 (combi ned)

Iterati on 5+6 (test & depl oy)

Iterati on 2

Iterati on 1

We are here

0% 100%

% Compl ete – Rel ease 1

Proj ect Tracki ng

0 212 pts

55 pts (49%)

Iterati on 0

I’ n 1 –34pts

Fix / Integrate $

DesignSpecifications

Use Cases / Functional Specs

Requirements Gathering

Project Plan/Estimation

$Release 1

Inception

$Release 2

$Release 3

Release 4 $

Waterfall compared with Agile

• Short Iterations• Frequent Releases• Earlier ROI

Lower cost of change through higher quality software

Agile system cost profile

Cost of change curve

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

Discipline in an Agile project

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

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.

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.

yEffort

When do we plan?

QuickStartQuickStart

Release 1Release 1

11 22 …… nn

Release NRelease N

11 22 …… mm

Initial Planning Constant Planning and Re-Planning

Stories

Iterations

Releases

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

ThoughtWorks Approach 2009

Technology