“Why Every IT Programme &
Project Should be Using an Agile
Delivery Approach”
Warren Tudor
ThoughtWorks UK
1st October 2008
© ThoughtWorks 2008
Warren Tudor
Innovation
Healthcare
New Media
Telecoms
Defence
Energy Trading
Project Manager &
Agile Transformation Consultant
© ThoughtWorks 2008
This Evening
IT Programmes & Projects – “state of play”
Introduction to the Agile alternative
Agile Principles & Benefits
Key Agile Delivery Practices
Agile for Enterprise Projects & Programmes
Risks to successful adoption - and mitigations
© ThoughtWorks 2008
IT Programmes & Projects
The Last 30 years
“Two thirds of (IT) projects
are challenged”
Source: The Standish Group CHAOS Reports
Over budget by 189%.
Source: The Standish Group CHAOS Reports
Over schedule by 220%.
Source: The Standish Group CHAOS Reports
66% of projects fail or are
‘marginal’.
Source: The Standish Group CHAOS Reports
$527 million written off
supply chain system abandoned
$3.45 billion tax-credit
overpayment
UK Inland Revenue
J Sainsbury plc
$160 million lost because of
ERP system problems
Hewlett-Packard
Poor Quality
Slow to Deliver
Expensive
A story
The business has an idea
Increase revenue
Decrease costs
Regulatory compliance
Cartoons courtesy of http://designcomics.org/
The idea is analysed
This takes time
The business sign off on the
requirements
Lots of requirements
Developers start writing code
It gets tested
Lots of time
Then deployed
Not quite what we wanted
Long feedback cycles
The business changes
Dates slip, scope gets cut, effort wasted
Value is not delivered
High project failure rate
High cost of change
Permanent state of maintenance
Little innovation
Unhappy stakeholders
Poor customer experience
Why Does This Happen ?
Business Challenges
– Constantly changing & complex
business environments
– High Expectations of Business
Sponsors
– Budgets constraints – ROI and
short-term breakeven critical
– Time to market is critical
– Dynamic technology landscape
© ThoughtWorks 2008
Traditional Project Delivery Methods
– Focus on plan activities not business value
– Over ambitious scoping
– Poor communications between project team
& business
– Long feedback loops
– Heavyweight planning & re-planning
– Deluded view of progress
© ThoughtWorks 2008
Poor Delivery Performance
– Rework from changing requirements
– Partially done work / task switching
– Volumes of design models & documents
– Extra features offering little benefit
– Lengthy and painful integration
– Poor quality software and/or software that
doesn’t meet the business needs
– Schedule delays, and budget overruns
– Lack of credibility with Business Sponsors and
Senior Executives
29
What if ?
– there was a different approach
Introduction to
the Agile alternative
© ThoughtWorks 2008
1990s
Frustration in Industry with Traditional Delivery Methods
Simultaneous development of Alternative Approaches
based on experience of “what actually works”
Realisation of common principles, practices, techniques
© 2001 Agile Alliance. http://www.agilemanifesto.org
31
2001
2000
“We are uncovering better ways of developing software
by doing it and helping others do it. Through this
work we have come to value:
XP | Extreme Programming (Kent Beck)
– IndividualsMethod
and interactions over processes
DSDM | Dynamic System Development
and tools.
– Working
software
over comprehensive
FDD | Feature Driven Development
(Jeff
DeLuca)
documentation.
Scrum (Ken Schwaber & Jeff Sutherland)
– Customer collaboration over contract
negotiation.
Crystal (Alistair Cockburn)
– Responding to change over following a plan.
Adaptive Software Development (Jim Highsmith)
That is, while there is value in the items on the right,
Lean Software Development (MarywePoppendieck)
value the items on the left more.”
Agile
manifesto
© 2001 Agile Alliance. http://www.agilemanifesto.org
32
Agile Myths
Agile is Not …..Hacking Code without any clear
Requirements
– No code is written without a customer approved
requirement
– Managing Change & Evolution of requirements is
an implicit part of Agile
© ThoughtWorks 2008
Agile Myths
Agile is Not ….. Hacking Code without any
Architecture or Design
– All Agile projects need an architecture
– Scale & complexity determines the form and level
of detail required
© ThoughtWorks 2008
Agile Myths
Agile is Not ….. Running a project with no
Structure, Processes or Controls
– Simple principles
– Strong technical disciplines
– Continuous Build, Integration & Testing measures
progress & improves control
© ThoughtWorks 2008
Agile Principles
 Highest priority - satisfy customers through early and
continuous delivery of valuable software capability
 Agile processes harness change for the customer's
competitive advantage
 Working systems are the primary measure of progress
 Business people and delivery team working together
and communicating daily throughout the project
 Ruthlessly eliminate waste
 Optimise overall delivery process - avoid local
optimisation
7/13/2017
Agile methods achieve 4 major benefits:
 Delivers business benefits earlier
 Manages delivery risk more effectively
 Enables close collaboration between Business & IT
 Lowers the cost of change in the future
 Step Change Improvements in Delivery Performance
How
 Simple Principles
 Pragmatic Practices & Techniques
 Tools
7/13/2017
37
Properties of Successful Projects
 Frequent Delivery
 Close Communication
 Reflective Improvement
= Properties
of Agile Projects
38
Agile Gives You
 Earlier Delivery of usable “Solution Slices”
 Enables Short Feedback Loops -> early customer
review & input to service development
 Technical Development & Integration Risks are
managed far more effectively
 Enables a Collaborative “one team” approach
across Customers, Delivery teams, Suppliers
 Ability to Adapt the delivery plan and take
advantage of Market Opportunities
 Delivers Better Quality Software much faster to
Market or Production
confidential
39
7/13/2017
Agile Gives You
Better
Faster
Cheaper
40
What if ?
– it were more like this
© ThoughtWorks 2008
Requirements
Gathering &
Analysis
Collaborative workshops
Requirements
Gathering &
Analysis
Agreeing a common Vision
…and Shared understanding
Requirements
Gathering &
Analysis
User Stories
“Just in time” elaboration
Requirements
Gathering &
Analysis
Adaptive
Planning
Collaborative prioritisation
Team estimation
Requirements
Gathering &
Analysis
I1
I2
Design/Build
Design/Build
Design/Build
Testing
Testing
Testing
Acceptance
Adaptive
Planning
Iterative
Development
I3
Acceptance
Acceptance
Spike Prototypes to solve
technical issues & risks
Continuous build &
integration
The right documentation
Requirements
Gathering &
Analysis
I1
I2
Design/Build
Design/Build
Design/Build
Testing
Testing
Testing
Acceptance
Adaptive
Planning
Iterative
Development
I3
Acceptance
Acceptance
Feedback – Showcases
to team & users
Feedback – Frequent
End User Testing
This really delivers Business Value
Key Agile Delivery Practices
© ThoughtWorks 2008
Iterative Development
“The single most important property of any
project, large or small, agile or not, is that of
delivering running, tested code to real users
every few months. The advantages are so
numerous that it is astonishing that any team
doesn’t do it”
-Alistair Cockburn
© ThoughtWorks 2008
Iterative Development
D-14
D0
Planning
D14
Release 1 Development
Scope
Definition / Analysis,
Architecture, Planning
Iteration
1
D0
Iteration
Kick Off
7/13/2017
D42
D28
Deploy
Planning
Iteration
2
Iteration
D7
Further Analysis
Design
Build
Integration /Test
QA
Business Sign Off
D56
D70
D84
R1 Live in
Production
R2 Live in
Production
Release 2 Development
Iteration
1
3
D98
Iteration
2
Iteration
3
Deploy
UAT, ORT,
Deployment
& Launch
D14
Showcase &
User Story
Signoff
51
Business Value Driven
Business Value Drives....
Scope Prioritisation
Release Planning
Architecture & Solution
7/13/2017
52
Business Value Driven
Relate to Business Case
Overall
Business
Priorities
Standard
Measurement
Criteria
Quantified
Financial
Assessment
Feedback
• Priority 1 Launch product XYZ
by Q4
• Priority 2 - Critical “In
production” fixes for
Customer ABC
• Cycle time reduction
• Cost avoidance/ reduction
• $/£s Cost Avoidance /
Reduction
• Customer experience
improvement
• $/£s New Revenue
• New Revenue generation
• Return on Investment
• Break Even
• Compliance
7/13/2017
53
Communication & Collaboration
Short,
Meetings
“LowFrequent,
Overhead”High
for Value
Delivery
Team
80% + of time – doing the Day Job !
7/13/2017
54
Communication & Collaboration
Daily “Stand Up” or Scrum Meetings
Developer, BA, QA “Huddles”
Customer Story Reviews
7/13/2017
55
Communication & Collaboration
Continuous Involvement
from Customers & End Users
Prioritisation,
Release & Iteration
Planning
Business Scenario
/User Story
Analysis
Iteration
Cycle
Acceptance Testing
& Feedback
Clarification during
Development
– Showcases
Use “Proxies” to supplement real Customers
56
7/13/2017
Risk Management
Agile Embeds Risk Management
Fail Fast and Fail Cheaply !
Accurate View of Progress
7/13/2017
57
Continuous Build, Automated Testing,
Rapid Deployment
Builds in Quality
Manages Integration Risk
Delivers Value
58
Agile Practices & Techniques
Adaptive
Planning
Project
Vision
Empowered
Teams
Automated
Testing
Customer
Engagement
Collaborative
Focus
Continuous
Integration
Continuous
Improvement
Test Driven
Development
Refactoring
Frequent
Releases
Simplicity
Minimal
Documentation
59
• Best practices
followed by Highly
Effective Teams
• Aligned to deliver
Business Value
• Drive Efficiency,
Productivity and
Quality
Regular Reflection and Continuous Improvement
Whyevery
waitfew
toweeks
the end of the
Review
projectgone
forwell
a process review ?
• What’s
• What’s gone not so well
• What do we want to change / improve
It’s too late !
© ThoughtWorks 2008
Agile for Enterprise Projects
& Programmes
© ThoughtWorks 2008
What types of Project Does Agile Work For?
Product
& Service
Innovation
Large Complex
Programmes involving
major Business Change
Service Oriented
Architecture /
Business Services
Enterprise Data
Warehouse & BI
© ThoughtWorks 2008
What does an Agile
Value
Reality
Focus
££$$
approach
bring to
Enterprise Programmes ?
© ThoughtWorks 2008
Project Kick Off Meeting
Stop “Super Sizing”
Less is More !
your Projects
© ThoughtWorks 2008
Scaling Agile
Project and Programme Teams
• Small hyper productive teams – 8 to 10 maximum
• Product Owner is a integral part of that team
• Team includes multiple skills / functions – BA,
Developers, QA, Customer
• Scale via multiple “independent” teams
• Structure along business architecture lines
© ThoughtWorks 2008
Scaling Agile
Agile Programme Governance & Management
• Programme Board responsible for overall
direction & priorities + resolution of escalated
issues – Nothing Else
• Delivery teams empowered to make all
operational decisions
• Frequent, high quality communication – cross
team, cross role & cross stakeholder
• Flexible commercial frameworks
© ThoughtWorks 2008
Scaling Agile
Agile Enables Successful Offshore Delivery
Offshoring Risks :
- Decreased communication bandwidth
• Daily collaboration between all team members in all locations
• Multiple lightweight communication modes
– Mismatched assumptions
• Short iterations provide rapid feedback
• Adaptive Planning handles changing requirements
– Complex integration points
• Continuous build & integration
• Automated regression testing
– Loss of visibility and control
• Working software is delivered every iteration
Offshore Delivery Total Cost rarely decreases,
Time-to-Market increases
67
Scaling Agile
Agile Enables Successful Offshore Delivery
• Focus on Communication
• Agile Programme Management
• Strong Technical Disciplines
• Collaborative Approach
across Functions / Teams
7/13/2017
68
Risks to successful adoption and mitigations
© ThoughtWorks 2008
Temptation to implement
Agile Practices piecemeal
Agile is only implemented
for Project Manage, or only
for Software Development
Or… Overdosing on a single
Methodology
Scrum
XP
DSDM
Both Management Practices
and Technical Disciplines
are essential
Wider Business
Stakeholders are not
engaged in the process
Lack of Executive
Sponsorship
Transformation is not
“Managed” effectively
Steering Group – senior
Implement
via
Real
Business & IT stakeholders
Projects
Transformation activities –
training, tools, process
Set Targets and Measure
Progress
Frequent review and
improvement of process
Acceptance of Mediocrity
Lack of ambition to achieve
“Step Change” improvements
It doesn’t have to be “crap”
Demonstrate success
Build team’s confidence,
motivation and ambition
“Too risky for my mission
critical applications”
Dixons
Point of Sale
200 people team
2 years non-delivery
Agile approach -> first
production release in 7 months
Guardian News & Sport Website
from legacy
technical environment to a new bespoke,
flexible and future-proof Java-based platform
in 6 Months
New releases to production – every 2 weeks
Westpac
BT Super for Life
AIIA Best Financial Application 2008
Superannuation product
First release in 8 months
Integrate with over 70 BT,
Westpac and third party
software systems, many of
which had never been
integrated before
“Agile Adoption will
take too long”
Major Benefits delivered in
3 months
Step Change Improvements
in 6 months
Selling the “Low Risk” Approach
• Project will not deliver value to the business for at
least a year, potentially 18 months
• We’ll spend 15-25% of the project time on coding
and unit testing and 75% on requirements, design,
documentation, administration, and management
• We’ll get all input from customers up-front and then
have them validate the product months later
• After we have invested tens of thousands, potentially
even millions, of dollars
Source: VERSIONONE
© ThoughtWorks 2008
In Case you’re not yet Sold….
• The business environment, strategy and requirements
will remain static throughout the project
• So no need to account for changing, evolving or new
requirements
• Project resources are just interchangeable parts in the
software industry’s wheel of productivity
• We’ll wait to the end to easily integrate all the
components, modules, etc. of the software
• We’ll also save acceptance testing until the very end
• The original plan - time, budget, and scope - will not
change this time, we’re certain of it
Source: VERSIONONE
© ThoughtWorks 2008
Mantra
“A religious or mystical syllable or
poem. They are primarily used as
spiritual conduits, words or vibrations
that instill one-pointed concentration in
the devotee”
© ThoughtWorks 2008
10 Agile Mantras
1.
Focus the delivery team and the customer on delivering business value
2.
Elaborate & deliver the highest priority requirements first
3.
Deliver “timeboxed” releases & iterations to enable rapid learning and feedback
from the customer
4.
Embrace change to enhance a product’s market suitability
5.
Ensure frequent, high quality communication between customer, delivery team &
suppliers
6.
Documentation should be “fit for purpose” but minimal
7.
Develop prototypes to facilitate understanding of business requirements and to
resolve technical risks & issues
8.
Evolve the solution within a flexible architectural framework
9.
Integrate continuously – multiple daily builds (& automatically regression test)
10. Ensure regular reflection and continuous improvement
88
7/13/2017
Rejecting Mediocrity
Better
Faster
Believing “Step Change”
Cheaper
improvements are Achievable
89
FailingDriving
our Business
Customers
Business
Success
90
“Why Every IT Programme
& Project Should be Using
an Agile Delivery
Approach”
© ThoughtWorks 2008
Questions
92