Introduction to Agile

1. Introduction to Agile

2. Agenda Introduction to Agile Early examples of agile projects 1

3. Software engineering originated together with the first computers in the 1940s 1941 1945 1952 1956 1957 1960 1964 First computer Algorithmic programming language Compiler and magnetic storage First key-board Fortran COBOL Basic • Early days • Experimentation and research • Programming by wiring • WWII communication encryption and decoding • Advent of programming • Management by schedule impossible • Everything open source • Programs rewritten with each new computer

4. A high rate of critical failures led to the “software crisis” 1965-1985 Examples Critical quality defects • Bugs and quality defects in commercial software applications caused critical/fatal incidents • F18 plane crashed due to missing exception condition • Colorado River flooding in 1983, due to faulty weather data and/or faulty model; too much water was kept dammed prior to spring thaws Budget overruns • Most large IT projects went significantly over schedule and budget • IBM’s OS/360 project in the 60’s many years and multi million dollars over schedule

5. Waterfall model was embraced as the way out of the crisis Publication Key messages Managing the development of large software systems: Concepts and Techniques - Dr. Winston Royce, 1970 • Software development is stepwise process 1. Requirements 2. Design 3. Implementation 4. Integration 5. Acceptance testing • Detailed requirements specification is essential “In order to procure $5 million dollars of software I would estimate a 1,500 page specification is about right ...” “I made a multi-million dollar mistake by not developing a coherent architecture for OS/360 before we started developing” Mythical man-month – Fred Brooks, 1975 • Invest a lot of time up front to 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 “How does a large software project get to be one year late? One day at a time!”

6. And it was widely accepted as the standard way of doing software development Waterfall Based on Winston Royce’s paper in 1970 V-Model DoD-STD-2167 Developed by the German Ministry of Defense in 1986 Developed by the US Dept of Defense in 1988

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

8. In the 1990’s a number of alternative, “light-weight” approaches emerged Methodology Pitched as Inventor/origin First implementation Extreme programming • Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements” • Kent Beck • USA • Pre-2000, • C3 project Chrysler; 8 developers Scrum • "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 Feature-driven development • Blends a number of industry-recognized best practices into a cohesive whole • Jeff De Luca • Australia • 1997 • 15 month, 50 person software development project at a large Singapore bank • December 1994 • Most large US IT defense projects 1994 - 2000 Mil-Std-498 • “If a system is developed in multiple builds, its requirements may not be fully defined until the final build” • Department of Defense • USA Dynamic systems development method • “A framework of controls and best practice for rapid application development” • DSDM Consortium • UK • 1995 • Been used by BT, Orange, Dept. of Health, Syndeco/Boston Globe, Sema Group, Logica and British Midlands Source: Press search

9. “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 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 Comprehensive documentation Contract negotiation Following a plan And in 2001, 17 prominent developers gathered in Snowbird Utah to declare the “Agile Manifesto” Individuals and Interactions Working software Customer collaboration Responding to change

10. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done 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 The 12 principles behind the Agile manifesto

11. . Early indications are that agile is more effective than waterfall Very few large IT projects deliver on time and on budget … ... whereas majority Agile projects are considered to be successful IT Projects delivering required functionality on budget and on time % projects Percentage of Agile projects considered successful % projects More than 80% 50% or less More than 50% Months SOURCE: “ChAOS: A recipe for success”, “ChAOS in the new millennium”, The Standish Group (1998, 2000), State of Agile development by VersionOne (2008);

12. 31 An adoption of Agile has become widespread Proportion of organisations with at least one Agile project in progress, 2008 Percent SOURCE: DDJ 2008 Agile Adoption Survey www.ambysoft.com

13. There are several advantages of Agile compared to traditional waterfall development Visibility Adaptability Business value Risk Time

14. But Agile is not a silver bullet Common pitfalls Failed projects Key shortcomings • Lack of long-term thinking leading to brittle, convoluted architecture • 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 mUSD 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 mUSD 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 4x cost Failure to commit to standards: Failure to meet UI design standard resulted in rewrite of large part of the program

15. Agile, “light-weight” methods (XP / Scrum) with On-location, senior developers More formal, but iterative methods (RUP, Evo) with offshore developers And agile is not always appropriate Recommended delivery models Waterfall/V-model with offshore developers High Degree of business knowledge and expertise required Low Low High Stability and understanding of requirements

16. To deliver maximum value, Agile must be adapted to the context, and managed properly Only use Agile when relevant Manage stakeholders • Communicate Agile methodology and rationale to business • Ensure representation of key stakeholders on all teams • Facilitate prioritizations • Communicate openly • When requirements are stable and well understood, V-model is faster and safer • Agile is not appropriate for junior developers Maximize value from Agile 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

17. SCRUM is the most widespread of the Agile methodologies Organizations use different methods … … and decide which practices to use within that method Agile method used most closely % of organizations Use of agile practices % of organizations Scrum Daily standup Scrum/XP hybrid Continuous integration XP Refactoring Custom/other hybrid Test-driven development DSDM Collective ownership Feature driven development Pair programming Other Source: Report: “State of Agile Development 2007,” VersionOne

18. Early agile projects Year Project Description Organization A major contribution to the X-15 success over the long run was its emphasis on incremental development The X-15 lessons learned NASA Dryden research facility 1950’s X-15 • Construction of hypersonic jet NASA 1972 Trident submarine • Command and control system for the first USA Trident submarine • Over one million lines of code IBM FSD The project was organized in four time-boxed iterations of 6 months each Integration engineering perspective The journal of systems and software 1972 Army Site Defence Software project • Software project for ballistic missile defence TRW 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

19. Early agile projects Year Project Description Organization Delivered in 45 time boxed iterations. Every one of those deliveries were on time and under budget Principles of software engineering Harlan Mills 1975 – 1979 LAMPS • USA navy helicopter ship system • 4 year, 200 person software effort FSD 1977 – 1980 Primary Avionics Software System • The central piece of NASA’s space shuttle software IBM FSD 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

21. Introduction to SCRUM

22. 1 2 3 4 5 6 7 Team selects how much to commit to do by Sprint’s end SCRUM is an iterative development approach with seven key components Input from end-users, customers, team, and other stakeholders Scrum master Daily scrum meeting and artifacts update Product backlog refinement Product owner Team Sprint 1-4 weeks Review Sprint planning meeting (parts 1 and 2) Sprint backlog No changes in duration or goal Potentially shippable product increment Product backlog Retrospective

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

24. 2.3 3.1 1.1 1. 2. 3. 4. 5. 7. 8. 9. 1.2 6. 1.3 2.1 2.2 1.1 3.2 3.1 1.3 1.2 2.2 2.1 2.4 2 The team decides how much they can commit to deliver in the next sprint Sprint backlog Product backlog Detailed user stories Team capacity 80 story points User stories Tasks Epics

25. 3 There are no changes to priorities or scope during the course of the sprint Burn down chart tracks delivery of committed scope Team has absolute certainty that scope, priorities or deadline will not change during the course of the sprint • Reinforces team focus on ensuring completion of committed scope • Forces product owner to put concentrated effort into prioritization

26. Agenda Introduction to Agile Early examples of agile projects 25

27. 4 The SCRUM master facilitates the delivery process Scrum master responsibilities • 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

28. 5 The daily SCRUM ensures team coordination and motivation Ground rules 5 Questions • Standing meeting in front of the visual management board • Max 15 minutes • No problem solving • Prepared update reports • 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? • Have I learned anything that the team should know about? • 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

29. 6 Each sprint should result in a potentially shippable product Sprint planning estimates must also include hygiene and completion activities 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

30. Purpose Ensure continuous and sustainable improvement in the way we work 7 The sprint retrospective is a vehicle to ensure continuous improvement Agenda Output • Improvement suggestions for team lead retrospective • Improvement tasks for sprint planning Time Topic Lead by 10:00 • Poker assessment of last iteration’s output • Quality • Reliability • Velocity • Customer value Team lead 10:40 • Identification of issues and root cause analysis • Internal team issues • External issues Team lead Target outcome • Joint team commitment to improve • Shared understanding for how to improve 11:20 Identification and prioritization of improvement ideas Team lead