1. Introducing Agile Processes into a Waterfall Organisation Chris Cooper-Bland, Senior Architect @ Endava Ltd

2. 2 Agenda What is Agile – Refresher What makes Organisations Waterfall? Introducing Change Change the process Change the Organisation What works Summary and Q&A How many of your organisations are using agile currently? How many are planning to?

3. 3 Delivering business value is hard… “ Of the work executed: “Many (possibly most) organisations lose as much as 45% of their total revenues due to costs associated with low quality” Six Sigma “Some 75 percent of most large-scale J2EE projects fail by missing both time and budget projections …” Mark Driver, Gartner “64% of features actually delivered are either rarely or never used” Jim Johnson, Standish Group

4. 4 Brief History of Development Methodologies WATERFALL (Royce) Requirements, design implementation, verification & maintenance 19608591 Methodologies 19801970 V-MODEL (Anon) Aligns testing to Waterfall development SPIRAL MODEL (Barry Boehm) Iterative RAD (James Martin) Prototyping, iterative, time-boxed, user driven RUP (Rational) Object oriented, iterative, time-boxed, user driven AGILE e.g. XP (Kent Beck) Incremental, user driven, low process 9899 WaterfallV-Model Spiral Model RAD RUP

5. 5 Agile Misconceptions? Agile means: “letting the programming team do whatever they need to with no project management, and no architecture, allowing a solution to emerge, the programmers will do all the testing necessary with Unit Tests…”

6. 6 What is Agile? http://www.agilemanifesto.org/ Management can tend to value the things on the right over the things on the left 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.

7. 7 Working Software Delivered Requirements Prioritised Requirements & Features “Backlog” Requirements Prioritised Iteration Scope Daily Scrum Meeting: 15 minutes Each teams member answers 3 questions: 1) What did I do since last meeting? 2) What obstacles are in my way? 3) What will I do before next meeting? Team-Level Planning Every 24hrs Every Iteration 4-6 weeks Applying Agile: Continuous integration; continuously monitored progress Agile project management - SCRUM

8. 8 Agile - XP explained (1) The Values Communication Simplicity Feedback Courage Respect(added in the latest version)

9. 9 Agile - XP explained (2) 1. Test First Programming Test First without code 2. The Planning Game - Business Stories - Customer decides, Prog. Implements 3. Small, Frequent Releases - Release early and release often 4. Always use the Simplest design that adds business value 5. System Metaphor - Programmers define a handful of classes and patterns that shape the core business problem and solution - Like a primitive Architecture 6. On-site Customer - Customer has authority to define functionality - encourages face-to-face dialogue 7. Refactoring Restructuring code without changing its functionality - Mainly Simplification 8. Pair Programming 9. Collective Code Ownership 10. Coding Standards - Everyone should use the same coding styles. 11. Continuous Integration - At least a few times a day - All unit tests must pass prior to integration - All functional tests must pass afterwards 12. Forty Hour Week ! - Tired programmers write poor code and make more mistakes

10. 10 Water Fall Organisations Accounting system – annual accounts, monthly returns Legal and regulatory controls Shareholders – 3 year plans, annual plans Interface with other organisations SLAs Reward System, annual event not immediate

11. 11 Random Example From Northern Constabulary

12. 12 Approach to Change Models to introduce change into the organisation Incremental approach Step change Thin threads Scope of change island or wholesale Prerequisites for change Blockers & enablers - timing Key influencers Other changes Disasters

13. 13 What to change – Best Practices Collaborative working Iterative projects Visual Modelling Risk based prioritisation Requirements Management Change Management Configuration Management Tools Traceability Most Useful Least Useful

14. 14 Factors for Success Choose the right project Size Importance visibility Get buy-in of senior management Communicate to all Use experienced people Don’t trust blindly effort = people * environment *size (process) - Walker Royce  Common sense – no silver bullets

15. 15 Changing the process - Integrating the method Advantages Single place to look Easy alignment People already understand parts Disadvantages May lead to confusion External staff don’t know it Overlaps and/or gaps

16. 16 Customising the method Project defined process documented in some form Organisational Tailoring of Method Organisation’s Software Engineering group Project Assurance (monitoring adherence to process and feedback for Software process improvement) Industry Standards. (e.g. ISO 12207,SW-CMM) Industry Methods development (e.g. Iterative, Agile) Standard Method specification Industry Level Organisational Level Project Level Macro-level tailoring Micro-level tailoring

17. 17 Changing the organisation People Team rewards Celebrate success Leadership – management must ask the right questions Communication, brown bags etc. Understand perceptions of success, what does finished mean? Quality/stage gates Senior Management control Estimating and budgeting Real options Portfolio planning Structure of the organisation

18. 18 Estimating This will prove problematic Identify an approach early, keep reviewing it Ideal model is to use a model calibrated with the actuals captured from your organisation, but …. Use model with someone else's metrics Use Industry model CoComo II Function point analysis Guess Planning game is usually too late to help

19. 19 The Budgeting Problem Source McConnell 1998 The Cone of Uncertainty

20. 20 Addressing it Convince management to make a fixed investment to establish costs Source McConnell 1998

21. 21 Application Project Portfolios Senior management must give authority and control to IT Use a portfolio management approach Define portfolio segments Apportion available budget Revalidate at stage gates, for balance and progress

22. 22 Real Options – a way of thinking Based on commodity options – right but not an obligation to buy at a point in the future Investment is continued only in favourable conditions, use probability models to predict future likelihood of return Can hedge different investments Allows management to be in control Share holders like it

23. 23 Structure – Skunk Works Lockhead Martin needed to develop secret projects, outside formal control Formed in June 1943 – Burbank CA 14 rules to ensure efficiency – similar to XP principles Now seen as technique for introducing change – but …

24. 24 Structure - Radical Changes Change the company structure of the organisation Create new spin-off company Joint venture Acquisition Change the internal structure New ventures department New project teams Existing Structure Bureaucracy Dynamic Agility required Waterfall XP No Change

25. 25 Don’t do this – if you want to fail Use integrated teams Sort out the development environment early Choose tools carefully Enterprise architecture is important for large/long lived systems One person needs to own the process vision with support from many Use partners experienced in the method

26. 26 What Works Well Configuration and change management, continuous integration Selling the method Books, presentations etc. Immersion for the project Briefings for the rest of the company Make them want it too…

27. 27 Summary The organisation will have to change too More you have to change the harder it is

28. 28 Resources Craig Larman’s books http://www.bcs-spa.org/ http://www.dsdm.org/ http://www.real- options.com/ http://www.real- options.com/

29. 29 Conclusion & Questions Contact Details Chris Cooper-Bland Senior Architect Chris.cooper- bland@endava.com