11. 1995 – The CHAOS Report
First comprehensive study on success and
failure of software projects
– Conducted by The Standish Group
– Updated roughly every two years
Survey of IT executive managers
– large and small businesses
– various industries
• inc. banking, securities, manufacturing, retail,
wholeale, health care, insurance, services and
government
12. Classifications
• “Successful”
– On time, on budget, all features
• “Challenged”
– Completed but over-budget, over time estimate,
missing features
• “Impaired”
– Canceled
13. Result of first study - 1994 data
Successful
16% Canceled
31%
Challenged
53%
14. Reasons for Challenged/Canceled, 1994
Lack of User Unrealistic Time Frames
Involvement
Lack of Planning
Incomplete
Requirements Project No Longer
Needed
Changing Requirements
Lack of Resources
Lack of Executive
Support Lack of Competence with
Technology Used
Unrealistic Expectations
16. How Are Big IT Projects Run?
IT is left to IT
Lack of involvement by stakeholders
Matrix organizations
People not dedicated & focused
Accountability is to department head, not project
lead
Poor communication
• No co-location
• Simple issues take a long time to resolve
17. How Are Big IT Projects Run?
Big, upfront requirements
Stakeholders will ask for the moon
Documentation so voluminous that often inconsistent &
conflicting
• Thick documentation = false sense of confidence
Business outcomes poorly/not defined
Lack of measurable, observable criteria for success
despite voluminous requirements documentation
• Ex. cost reduction targets, customer satisfaction,
market share, process handling time
18. The Problem with “Waterfall”
Mistakes are hard to
find in early stages
Change becomes
more expensive in
later stages
20. Reasons for Success, '04 - '08
• User involvement • Project manager
• Executive management expertise
support • Financial management
• Clear business • Skilled resources
objectives • Formal methodology
• Optimizing scope • Standard tools and
• Agile process methodology
21. What is Agile?
Family of methodologies that
advocate “lightweight” and
“human” software development
processes
– Extreme Programming (XP), Scrum,
Kanban, Lean, Crystal, Agile Unified
Process...
Coined in 2001 by the creators of
similar methodologies reacting to
“heavyweight” methodologies
– “heavyweight”: too much work that does
not contribute to successful software
project
22. What is Agile?
Emphasis on
Customer satisfaction
Job satisfaction
Removal of things that do not contribute to above
23. What is Agile?
Culture
Values and attitude of people involved are just as
important as processes
Automation for Quick Feedback
Automated tests, code quality metrics, acceptance
criteria, automated build & deployment...
25. Aspects of Software Development
• Project - No one
Management methodology covers
• Engineering all aspects
• Business Analysis - No one
methodology covers
• Quality Assurance all situations
• User Experience
• Others...
26. Some Agile Practices
Interdisciplinary, co-located teams
Ex. Qwest Communications project
Short iterations
Deliver working systems for customer feedback
Test-Driven Development
Define success before you build, down to the
smallest unit
27. Some Agile Practices
Continuous Integration
Automatically build and deploy entire system
multiple times a day, running automated tests
and other quality tools
Refactoring
Constantly improving code design to make it easy
to accommodate change
DevOps
Integrate development and operations into a
seamless, automated practice
28. Are Agile Practices the Answer?
NO
Many organizations have adopted Agile
practices with poor results
30. Why Agile Fails
• Culture of mistrust
• Performance measures not aligned towards
collaboration
• Capability of personnel
• Agile authors and consultants that preach
silver bullets & snake oil
– Example... “leaderless teams”... what?
31. Improving the Success Rate
• No silver bullets
– Slow and steady changes
– Each company is different
• Changing not just practices, but also culture
and performance measures
– Align towards collaboration
• Ex: Reward overall project success, not just specific
department deliverables
• Smaller project scopes, measurable
outcomes
32. Improving the Success Rate
• Focused, multidisciplinary, co-located teams
– Avoid matrix organization
– IT is too important to leave to IT!
• Teams with end-to-end responsibility
– Requirements definition, design, development,
testing, deployment, and business results
• Did I say no silver bullets?
– Experienced, pragmatic coaches can help
33. The Agile Manifesto
We are uncovering better ways of developing software
by doing it and helping others do it. Through this
work we have come to value:
Individuals and interactions over processes and
tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
34. Agile at Orange & Bronze
Been doing Agile since its foundation in 2005
Before it became mainstream
We've tried different methodologies and practices
XP, Scrum, Kanban, Lean...
Not all practices work in all conditions
The first to offer training & coaching in Agile
methodologies and practices
Scrum, TDD, Agile Business Analysis, Agile QA, etc
Trainers/coaches are seasoned practitioners
Officers & architects speak at Agile conferences
here and abroad
35. Some of Our Clients
Software Development Training & Coaching
Both