Introduction to Agile 0 Agenda Introduction to

Introduction to Agile 0

Agenda Introduction to Agile Early examples of agile projects 1 1

Software engineering originated together with the first computers in the 1940 s 1945 Compiler and magnetic storage Early days ▪ Experimentation and research ▪ Programming by wiring ▪ WWII communication encryption and decoding 1956 1957 1960 First Fortran COBOL keyboard 1964 Basic Advent of programming ▪ Management by schedule impossible ▪ Everything open source ▪ Programs rewritten with each new computer Printed 5/18/2010 8: 28: 55 AM First Algorithmic computer programming language 1952 Working Draft - Last Modified 10/20/2010 7: 57: 24 AM 1941

A high rate of critical failures led to the “software crisis” 1965 -1985 Critical quality defects ▪ Bugs and quality defects in commercial software applications caused critical/fatal incidents F 18 plane crashed due to missing exception condition ▪ IBM’s OS/360 project in the 60’s many years and multi million dollars over schedule Budget overruns ▪ Most large IT projects went significantly over schedule and budget ▪ Colorado River flooding in 1983, due to faulty weather data and/or faulty model; too much water was kept dammed prior to spring thaws Printed 5/18/2010 8: 28: 55 AM ▪ Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Examples

Waterfall model was embraced as the way out of the crisis Key messages ▪ Mythical man-month – Fred Brooks, 1975 ▪ Invest a lot of time up front to ▪ Software development is stepwise process 1. Requirements 2. Design 3. Implementation 4. Integration 5. Acceptance testing Detailed requirements specification is essential build a coherent architectural design ▪ Adding more developers late in the project will only slow things down ▪ Create a detailed milestone schedule, and manage hard towards it “In order to procure $5 million dollars of software I would estimate a 1, 500 page specification is about right. . . ” “I made a multimillion dollar mistake by not developing a coherent architecture for OS/360 before we started developing” “How does a large software project get to be one year late? One day at a time!” Printed 5/18/2010 8: 28: 55 AM Managing the development of large software systems: Concepts and Techniques - Dr. Winston Royce, 1970 Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Publication

And it was widely accepted as the standard way of doing software development Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Waterfall Based on Winston Royce’s paper in 1970 Developed by the German Ministry of Defense in 1986 Do. D-STD-2167 Developed by the US Dept of Defense in 1988 Printed 5/18/2010 8: 28: 55 AM V-Model

But it gradually became apparent that waterfall development does not always produce the desired results Business and user involvement Requirement specifications …which leads to a very big part of the delivered functionality being redundant Features actually being used by the customer Percent Only IT involvement Always Detailed design Often Sometimes Unit testing and integration Acceptance testing Rarely SOURCE: J. Johnson, Standish Group, Keynote speech at XP 2002 conference in Sardinia, Italia 2002 Printed 5/18/2010 8: 28: 55 AM Never Implementation Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Traditional IT projects have scarce business and user involvement…

In the 1990’s a number of alternative, “light-weight” approaches emerged Extreme programming Scrum Mil-Std-498 Dynamic systems development method Source: Press search Inventor/origin First implementation ▪ Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements” ▪ ▪ Kent Beck USA ▪ ▪ Pre-2000, C 3 project Chrysler; 8 developers ▪ "Management and control process that cuts through complexity" ▪ ▪ Jeff Sutherland, Ken Schwaber, Mike Beedle USA 1994 Advanced Development Methods process automation software. 8 developers. VMARK - OO software development environments ▪ Blends a number of industryrecognized best practices into a cohesive whole ▪ ▪ Jeff De Luca Australia ▪ ▪ 1997 15 month, 50 person software development project at a large Singapore bank ▪ “If a system is developed in multiple builds, its requirements may not be fully defined until the final build” ▪ Department of Defense USA ▪ ▪ December 1994 Most large US IT defense projects 1994 - 2000 “A framework of controls and best practice for rapid application development” ▪ ▪ ▪ 1995 Been used by BT, Orange, Dept. of Health, Syndeco/Boston Globe, Sema Group, Logica and British Midlands ▪ ▪ ▪ DSDM Consortium UK Printed 5/18/2010 8: 28: 55 AM Feature-driven development Pitched as Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Methodology

And in 2001, 17 prominent developers gathered in Snowbird Utah to declare the “Agile Manifesto” That is, while there is value in the items on the right, we value the items on the left more. ” - The Agile Manifesto, February 2001 Processes and tools Working software Comprehensive documentation Customer collaboration Contract negotiation Responding to change Following a plan Printed 5/18/2010 8: 28: 55 AM Individuals and Interactions Working Draft - Last Modified 10/20/2010 7: 57: 24 AM “We are uncovering better ways of developing software by doing it and helping others do it. Through the 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

The 12 principles behind the Agile manifesto Continuous attention to technical excellence and good design enhances agility Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage The most efficient and effective method of conveying information to and within a development team is face-to-face conversation Simplicity--the art of maximizing the amount of work not done--is essential Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Working software is the primary measure of progress The best architectures, requirements, and designs emerge from self-organizing teams Business people and developers must work together daily throughout the project Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly Printed 5/18/2010 8: 28: 55 AM Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Early indications are that agile is more effective than waterfall IT Projects delivering required functionality on budget and on time % projects . . . whereas majority Agile projects are considered to be successful Percentage of Agile projects considered successful % projects 50% or less More than 80% Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Very few large IT projects deliver on time and on budget … Printed 5/18/2010 8: 28: 55 AM Months More than 50% SOURCE: “Ch. AOS: A recipe for success”, “Ch. AOS in the new millennium”, The Standish Group (1998, 2000), State of Agile development by Version. One (2008);

An adoption of Agile has become widespread Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Proportion of organisations with at least one Agile project in progress, 2008 Percent Printed 5/18/2010 8: 28: 55 AM SOURCE: DDJ 2008 Agile Adoption Survey www. ambysoft. com

There are several advantages of Agile compared to traditional waterfall development Business value Risk Time Printed 5/18/2010 8: 28: 55 AM Adaptability Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Visibility

But Agile is not a silver bullet Common pitfalls ▪ Lack of clarity about requirements ▪ Business not being able to or willing to prioritize requests ▪ Too much testing deferred to the customer, causing irritation ▪ Developers doing what they “feel” is right instead of sticking to the agreed process and standards Railhead: US department of homeland security spent ~500 m. USD on a IT project to enable sharing, fusing and analysis of terrorist intelligence data across government agencies. Poor architecture: Same data field present in 463 tables Lack of documentation: 295 of these tables not documented Functionality not implemented: Poor database searchability. Top priority functionality not being delivered, no reason given CJEP: Australian Justice department spent 54 m. USD on a IT project to facilitate the flow of documents between police, legal representatives, the courts and other related agencies to improve efficiency of the court system Poor planning: Severe underestimation of complexity. Poor scoping leading to final deliverable 9 years delayed at 4 x cost Failure to commit to standards: Failure to meet UI design standard resulted in rewrite of large part of the program Printed 5/18/2010 8: 28: 55 AM Lack of long-term thinking leading to brittle, convoluted architecture Key shortcomings Working Draft - Last Modified 10/20/2010 7: 57: 24 AM ▪ Failed projects

And agile is not always appropriate Recommended delivery models Waterfall/V-model with offshore developers More formal, but iterative methods (RUP, Evo) with offshore developers Low High Stability and understanding of requirements Printed 5/18/2010 8: 28: 55 AM Degree of business knowledge and expertise required Agile, “light-weight” methods (XP / Scrum) with On-location, senior developers Working Draft - Last Modified 10/20/2010 7: 57: 24 AM High

To deliver maximum value, Agile must be adapted to the context, and managed properly ▪ ▪ Manage stakeholders ▪ When requirements are stable and well understood, V-model is faster and safer Agile is not appropriate for junior developers ▪ ▪ ▪ Communicate Agile methodology and rationale to business Ensure representation of key stakeholders on all teams Facilitate prioritizations Communicate openly Adapt to situation Manage process ▪ ▪ Leverage existing tools and infrastructure Assess existing skill sets, and ensure proper coaching Have at least one agile “champion” per team ▪ Involve all team members in iteration planning sessions Ensure compliance with key principles: – Continuous testing and integration – Ongoing attention to simplification and refactoring Printed 5/18/2010 8: 28: 55 AM Maximize value from Agile Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Only use Agile when relevant

SCRUM is the most widespread of the Agile methodologies Agile method used most closely % of organizations Source: Report: “State of Agile Development 2007, ” Version. One Use of agile practices % of organizations Daily standup Continuous integration Refactoring Test-driven development Collective ownership Pair programming Printed 5/18/2010 8: 28: 55 AM Scr um Scrum/XP hybrid X P Custom/other hybrid DS Feature DM driven developm Oth ent er … and decide which practices to use within that method Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Organizations use different methods …

Early agile projects Project Description Organization 1950’s X-15 ▪ NASA 1972 Trident submarine ▪ 1972 Army Site Defence Software project ▪ Command IBM FSD control system for the first USA Trident submarine Over one million lines of code Software project TRW for ballistic missile defence The X-15 lessons learned NASA Dryden research facility The project was organized in four time-boxed iterations of 6 months each Integration engineering perspective The journal of systems and software The project was developed in 5 iterations, iteration 1 did the tracking of a single object. By iteration 5 two years later the project was complete Managing the development of reliable software International conference on reliable software Printed 5/18/2010 8: 28: 55 AM ▪ Construction of hypersonic jet A major contribution to the X-15 success over the long run was its emphasis on incremental development Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Year

Early agile projects Project Description 1975 – 1979 LAMPS ▪ ▪ 1977 – 1980 ▪ USA navy FSD helicopter ship system 4 year, 200 person software effort The central piece of NASA’s space shuttle software IBM FSD Delivered in 45 time boxed iterations. Every one of those deliveries were on time and under budget Principles of software engineering Harlan Mills 17 iterations over 31 months. Traditional development not suitable because of evolving requirements Design, development, integration, space shuttle flight software system Communications of the ACM Printed 5/18/2010 8: 28: 55 AM Primary Avionics Software System Organization Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Year

Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Printed 5/18/2010 8: 28: 55 AM

Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Introduction to SCRUM Printed 5/18/2010 8: 28: 55 AM

SCRUM is an iterative development approach with seven key components 1 Product owner 4 Scrum master Product backlog refinement Team Sprint 1 -4 weeks Sprint backlog No changes in duration or goal Review 6 Potentially shippable product increment 7 Retrospective Printed 5/18/2010 8: 28: 55 AM Product backlog Daily scrum meeting and artifacts update 3 2 Team selects how much to commit to do by Sprint’s end Sprint planning meeting (parts 1 and 2) 5 Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Input from end-users, customers, team, and other stakeholders

1 The product owner owns and prioritizes the product backlog 1. Ensure product relevance ▪ Align with business strategy ▪ Review with internal stakeholders ▪ Arrange customer reviews ▪ Source company insight 3. Safeguard quality ▪ Provide feedback on emerging solution ▪ Approve or reject release candidates Value to customers Value to business Ranked as “very important” by 73% of customers ▪ Increase C. S. , and thereby market share 30 2. Instant Reduce average booking wait time from confirmation 6 hours to 15 seconds ▪ ▪ Increase C. S. Reduce cost by automating internal processes 85 3. IT supported Faster, more issue effective and resolution transparent resolution process 4. . . 5. . . 6. . … ▪ ▪ Increase C. S. Reduce cost by automating internal processes 50 Feature 1. Proactive notification to EAT changes ▪ ▪ ▪ Effort x y z Printed 5/18/2010 8: 28: 55 AM 2. Maximize return on investment ▪ Prioritize features using highlevel business cases ▪ Revise prioritization based on effort estimates ▪ Generate and gather innovation and improvement ideas Product backlog Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Product owner responsibilities

2 The team decides how much they can commit to deliver in the next sprint 1. 1 2. 1. 2 3. 1. 3 4. 2. 1 5. 2. 2 1. 2 2. 2 s Team capacity 80 story points 2. 1 7. 2. 4 1. 3 8. 3. 1 1. 1 9. 3. 2 Ta sk r st o ri es 3. 1 se 2. 3 U ic Ep 6. s 1. Printed 5/18/2010 8: 28: 55 AM Detailed user stories Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Product backlog Sprint backlog

3 There are no changes to priorities or scope during the course of the sprint ▪ ▪ Reinforces team focus on ensuring completion of committed scope Forces product owner to put concentrated effort into prioritization Printed 5/18/2010 8: 28: 55 AM Team has absolute certainty that scope, priorities or deadline will not change during the course of the sprint Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Burn down chart tracks delivery of committed scope

Agenda Early examples of agile projects Printed 5/18/2010 8: 28: 55 AM 25 Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Introduction to Agile

4 The SCRUM master facilitates the delivery process ▪ ▪ ▪ Printed 5/18/2010 8: 28: 55 AM ▪ Conduct daily SCRUMs Facilitate removal of impediments Guide and coach team and organization on skilful use of SCRUM Facilitate sprint planning and sprint retrospective Protect the team from outside disturbances Remind the team on their commitments Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Scrum master responsibilities

5 The daily SCRUM ensures team coordination and motivation 5 Questions 1. Standing meeting in front of the visual management board 2. Max 15 minutes 3. No problem solving 4. Prepared update reports 1. 2. 3. 4. What have I done since the last SCRUM? What will I do until the next SCRUM? Do I have any blocks? Are there any new tasks that need to be added? 5. Have I learned anything that the team should know about? Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Ground rules Printed 5/18/2010 8: 28: 55 AM ▪ ▪ Entire team is on same page Everybody knows who is working on what Agreed commitment and priorities are reinforced Issues and blocks are escalated early

6 Each sprint should result in a potentially shippable product Documentation, testing, user verification/quality assurance is done within the sprint User acceptance testing can start earlier ▪ Team gets feedback sooner ▪ Issues are uncovered faster ▪ Documentation is written while design decisions are fresh in memory ▪ Attention to quality is constant throughout the development cycle Printed 5/18/2010 8: 28: 55 AM ▪ Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Sprint planning estimates must also include hygiene and completion activities

7 The sprint retrospective is a vehicle to ensure continuous improvement Ensure continuous and sustainable improvement in the way we work Agenda Output Topic Lead by 10: 00 Poker assessment of last iteration’s output ▪ Quality ▪ Reliability ▪ Velocity ▪ Customer value Team lead Identification of issues and root cause analysis ▪ Internal team issues ▪ External issues Team lead Identification and prioritization of improvement ideas Team lead 10: 40 11: 20 ▪ ▪ Improvement suggestions for team lead retrospective Improvement tasks for sprint planning Target outcome ▪ ▪ Joint team commitment to improve Shared understanding for how to improve Printed 5/18/2010 8: 28: 55 AM Time Working Draft - Last Modified 10/20/2010 7: 57: 24 AM Purpose