This document discusses how a large company implemented Agile practices across multiple projects. It describes how a pilot project using Scrum was successful, delivering earlier and under budget. This led the company to rollout Scrum across other projects, which involved scaling practices, using tools like version control and continuous integration, and addressing challenges of distributed teams. Key factors for success included accurate prioritization, responsive impediment removal, focus on core practices, the right team composition, and commitment from both IT and business stakeholders.

1. Making Agile Work For Large Projects Mark Drysdale

2. Agenda Traditional Delivery What is Agile Scrum Case Study – Company X History Pilot Rollout 2

3. The Risks of Software Development Delivering too little, too late Discovering functional needs late in the project Building the right things wrong Building more than you need Adding complexity which leads to non-maintainability Poor quality software Software buggy Software not maintainable

4. Industry Statistics

5. Agile is … the Methods AGILE Lean Thinking Queuing Theory Theory of Constraints eXtreme Programming (1996) Scrum (2001) DSDM (1995) Feature Driven Development (1997) Crystal (mid 1990s) Kanban (2008 ish) AUP/OpenUP Lean Software Development (2003)

6. Contrasting Waterfall with Agile Analysis Design Code Test Deploy Waterfall Time Analysis Analysis Analysis Analysis Design Analysis Architecture Releasable Releasable Releasable Deploy Design Design Design Code Code Code Code Agile Test Test Test Test

7. The Scrum Process Daily Scrum Meeting 24hours Sprint review Sprint Backlog tasks expanded by team Sprint Planning Sprint Backlog Potentially Shippable Product Increment Product Backlog Anyone can contribute items Prioritized by Product Owner

8. Company X Company X spent £100 million on tech refresh and consolidation 80 legacy system consolidated to 1 All other major projects suspended for 4 years Was it a Success? It has enabled Company X to take the next step... But... 2 years late 500+ defects in Live Backlog of over 200 Change Requests Business has had to accept over 150 manual work arounds New CTO Previously experience with Scrum at … Dictated that 4 Project would be run as Scrum in first year Commercial in Confidence 8 Why Change?

9. Company X – Pilot Commercial in Confidence 9 Ideal Agile Project Candidate Checklist

10. Company X Pilot – Providers Online First major web initiative Java based CMS Java Struts portlets .Netwebservices .Net backend Oracle Database 12 Month projects £2.2 million budget Team of 22 Java and .Net teams had never worked together Testers from 3 suppliers Project in total had 6 different suppliers Only 3 Company X permanent members Disengaged Product Owner Commercial in Confidence 10 What????

11. Company X Pilot – Providers Online Co-located everyone! Moved out to another building Created our own build servers Own code branch Implemented CI for Java Manual daily builds for .Net Created our own System Test Environments 2 Scrum teams Cross functional Scrum Master 3 Java 2 .Net 1 Html 1 Business Analyst 2 Manual testers 1 Automation Tester Commercial in Confidence 11 First Steps

12. Company X Pilot – Providers Online Complete UAT 2 weeks early Order of magnitude less defects discovered in UAT Delivered on time and under budget £1.9 million Commercial in Confidence 12 What a Success!

14. Identifies cross-team dependencies

15. Escalate dependencies

16. Coordinate technical issues

18. Resolves backlog dependencies and conflicts

19. Enables prioritisation across teams

20. Shields teams from conflicting change

21. Ensures single visionProduct Owner Product Owner Product Owner Group Product Owner Product Owner

23. Cut build time from hours to 10 min

24. Continuous Integration

25. 10-15 builds a day

26. TDD

27. MsTest

28. Rhino Mocks

29. Automation of Build

30. Nightly Builds and Deployments

31. Automation of Regression tests

32. QTP Pack takes 7 hours to run

34. Distributed Scrum - How to ramping up Cell based replication

35. Distributed Scrum - How to ramping up Distribute first team

36. Distributed Scrum - How to ramping up Distribute second team

37. Distributed Scrum - How to ramping up Seed third team from members of first teams

38. Distributed Scrum - Enablers Video conferencing For daily stand ups Planning Retrospectives Digital Scrum boards Wiki and online velocity charts Scrum teams in offices/grouped desks Offshore/Onshore Exchange Continually moving team members between locations

40. A committed development team

41. Knowledgeable testersHave the right attitude

42. Pitfalls – What will prevent success? Lack of commitment From IT – looking for the benefits of agile without the cost of change From the business – paying lip-service to the change with an inappropriate Product Owner Driving from the wrong direction The agile transition is a change in the relationship between IT and the business Lack of understanding Rigidly applying all aspects of a methodology, even when they prove to be detrimental Adapting agile practices to suit existing processes, teams, documents and standards Having unrealistic expectations Transitioning to agile is not an overnight process In SCRUM, the first Sprint for a new, blended team should be expected to fail