“Why Every IT Programme & Project Should be Using an Agile Delivery Approach” Warren Tudor Thought. Works UK 1 st October 2008 © Thought. Works 2008
Warren Tudor Innovation Defence Healthcare New Media Telecoms Project Manager & Agile Transformation Consultant © Thought. Works 2008 Energy Trading
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 © Thought. Works 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 el gh Hi lev de sig n De tail e dd esi gn
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 © Thought. Works 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 © Thought. Works 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 © Thought. Works 2008
1990 s 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) – Individuals and interactions over processes DSDM | Dynamic System Development Method and tools. – Working software over comprehensive FDD | Feature Driven Development (Jeff De. Luca) 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 (Marywe value the items on the left more. ” Poppendieck) 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 © Thought. Works 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 © Thought. Works 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 © Thought. Works 2008
Agile Principles u Highest priority - satisfy customers through early and continuous delivery of valuable software capability u Agile processes harness change for the customer's competitive advantage u Working systems are the primary measure of progress u Business people and delivery team working together and communicating daily throughout the project u Ruthlessly eliminate waste u Optimise overall delivery process - avoid local optimisation 3/19/2018
Agile methods achieve 4 major benefits: u Delivers business benefits earlier u Manages delivery risk more effectively u Enables close collaboration between Business & IT u Lowers the cost of change in the future Ø Step Change Improvements in Delivery Performance How u Simple Principles u Pragmatic Practices & Techniques u Tools 3/19/2018 37
Properties of Successful Projects u Frequent Delivery u Close Communication u Reflective Improvement = Properties of Agile Projects 38
Agile Gives You u Earlier Delivery of usable “Solution Slices” u Enables Short Feedback Loops -> early customer review & input to service development u Technical Development & Integration Risks are managed far more effectively u Enables a Collaborative “one team” approach across Customers, Delivery teams, Suppliers u Ability to Adapt the delivery plan and take advantage of Market Opportunities u Delivers Better Quality Software much faster to Market or Production confidential 39 3/19/2018
Agile Gives You Better Faster Cheaper 40
What if ? – it were more like this © Thought. Works 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 I 1 I 2 I 3 Design/Build Testing Acceptance Adaptive Planning Iterative Development Acceptance Spike Prototypes to solve technical issues & risks Continuous build & integration The right documentation
Requirements Gathering & Analysis I 1 I 2 I 3 Design/Build Testing Acceptance Adaptive Planning Iterative Development Acceptance Feedback – Showcases to team & users Feedback – Frequent End User Testing
This really delivers Business Value
Key Agile Delivery Practices © Thought. Works 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 © Thought. Works 2008
Iterative Development D-14 D 0 Planning D 14 Release 1 Development Scope Definition / Analysis, Architecture, Planning Iteration 1 D 0 Iteration Kick Off 3/19/2018 D 42 D 28 D 56 Deploy D 70 D 84 R 1 Live in Production R 2 Live in Production Planning Iteration 2 Iteration D 7 Further Analysis Design Build Integration /Test QA Business Sign Off D 98 Deploy Iteration 1 3 Iteration 2 Iteration 3 UAT, ORT, Deployment & Launch D 14 Showcase & User Story Signoff 51
Business Value Driven Business Value Drives. . Scope Prioritisation Release Planning Architecture & Solution 3/19/2018 52
Business Value Driven Relate to Business Case Overall Business Priorities Standard Measurement Criteria Quantified Financial Assessment Feedback • Priority 1 Launch product XYZ by Q 4 • 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 3/19/2018 53
Communication & Collaboration Short, Frequent, High Value Meetings “Low Overhead” for Delivery Team 80% + of time – doing the Day Job ! 3/19/2018 54
Communication & Collaboration Daily “Stand Up” or Scrum Meetings Developer, BA, QA “Huddles” Customer Story Reviews 3/19/2018 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 3/19/2018
Risk Management Agile Embeds Risk Management Fail Fast and Fail Cheaply ! Accurate View of Progress 3/19/2018 57
Continuous Build, Automated Testing, Rapid Deployment Builds in Quality Manages Integration Risk Delivers Value 58
Agile Practices & Techniques • Best practices followed by Highly Effective Teams • Aligned to deliver Business Value • Drive Efficiency, Productivity and Quality 59
Regular Reflection and Continuous Improvement Why wait to the end of the Review every few weeks project for a process review ? • What’s gone well • What’s gone not so well • What do we want to change / improve It’s too late ! © Thought. Works 2008
Agile for Enterprise Projects & Programmes © Thought. Works 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 © Thought. Works 2008
What does an Agile Value bring Reality Focus approach ££$$ to Enterprise Programmes ? © Thought. Works 2008
Project Kick Off Meeting Stop “Super Sizing” Less is More ! your Projects © Thought. Works 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 © Thought. Works 2008
Scaling 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 © Thought. Works 2008
Scaling 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 Enables Successful Offshore Delivery • Focus on Communication • Agile Programme Management • Strong Technical Disciplines • Collaborative Approach across Functions / Teams 3/19/2018 68
Risks to successful adoption and mitigations © Thought. Works 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 Implementstakeholders via Real Business & IT 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 © Thought. Works 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 © Thought. Works 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” © Thought. Works 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 3/19/2018
Rejecting Mediocrity Better Faster Change” Believing “Step Cheaper. Achievable improvements are 89
Failing our Business Driving Customers Business Success 90
“Why Every IT Programme & Project Should be Using an Agile Delivery Approach” © Thought. Works 2008
Questions 92
Скачать презентацию Why Every IT Programme Project Should be
33989fddbcf6b8e121df0d1fd2ca0143.ppt