This document provides an overview of Agile software development. It begins by defining Agile development as empowering people through constant feedback and acknowledging change. It then outlines the history of Agile methods from the 1970s to today. Key figures who developed methods like Scrum, Extreme Programming, and others are mentioned. The Agile Manifesto values individuals, working software, customer collaboration and responding to change. Core Agile principles are also outlined. Common Agile practices around design, testing, planning and communication are then explored. Finally, it discusses popular Agile methodologies like Scrum, XP, FDD and Lean and key themes across methods.

1. Agile Software DevelopmentPrimer

3. What is Agile Development?

4. "The ability to move faster than those things that can harm your project…"

5. Agile Development is a method of building software by empowering and trusting people, acknowledgingchange as a norm, and promoting constant feedback

6. Agile Software Development ... the History1974 An adaptive software development process documented, 1991 “Rapid Application Development” published1995 DSDM Framework published1995 SCRUM presented at OOPSLA1996 XP Practices developed on C3 project1997 FDD processes designed by Jeff De Luca1999 FDD described in “Java Modeling in Color with UML”1999 “Extreme Programming Explained” published1999 “Adaptive Software Development” published2001 Crystal Light methodologies described in Cutter IT Journal, 2001 Agile Manifesto written2003 “Lean Software Development: An Agile Toolkit for Software Development Managers” published

7. Agile Software Development ... the HistoryKent Beck – Creator of XP, TDD Mike Beedle – “Agile Software Development with Scrum” c.KenSchwaber, 2002Arie van Bennekum – RAD, DSDM Alistair Cockburn – Use Cases, Crystal Methodologies Ward Cunningham – Creator of XP, wiki’s, design patterns Martin Fowler – the UML, Author of “Refactoring” & “Planning XP” c.Beck James Grenning Jim Highsmith – Creator of ASD, “Adaptive Software Development” (1999) Andrew Hunt – Author, Partner “The Pragmatic Programmer” c. D. Thomas Ron Jeffries – Creator of XP, “Extreme Programming Installed” (2000) Jon Kern - Brian Marick – Context Driven Testing Robert C. Martin – Author “Designing Object Oriented C++” (1995) Steve Mellor - Shlaer-Mellor method, Executable UML, MDA Ken Schwaber- Creator of SCRUM, “The Enterprise & SCRUM” 2007 Jeff Sutherland – Creator of SCRUM Dave Thomas – Author, Partner “The Pragmatic Programmer”

8. The Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doingit and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more

15. Agile PrinciplesOur highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

16. Agile Principles1. Satisfy the Customer2. Welcome Change3. Deliver Frequently4. Work as a Team5. Motivate People6. Communicate Face to Face

17. Agile Principles

18. Agile Principles

19. Agile Practices

20. Agile PracticesDesign & Programming* Build Automation * Automated Deployment Continuous Integration * Simple Design Collective OwnershipFeature Teams * Refactoring Pair ProgrammingTesting* Automated Unit Testing Acceptance Tests * Test Driven DevelopmentSmall ReleasesPlanning GameBlitz PlanningIterative DevelopmentWorking Without Iterations (Wall work Queue)Short Iteration Cycles The Task CycleCommunication & CollaborationStand Up Meetings Daily “Scrum” Meeting Co-located TeamDocumentationStart of Project DocumentationDesign DocumentationOther approaches

21. Design & Programming *Build Automation *Automated Deployment Continuous Integration *Simple Design Collective Ownership*Refactoring Pair Programming

22. Build Automation

23. Automated Deployment

24. Continuous Integration

25. Simple Design

26. Collective Ownership

27. Feature Teams

28. Refactoring

29. Pair Programming

30. Testing *Automated Unit Testing Acceptance Tests *Test Driven Development

31. Automated Unit Testing

32. Acceptance Tests

33. Test Driven Development

34. Agile Management User Stories / Story Writing Workshop Release Planning Activities Iterative Development The Customer Communication & Collaboration Documentation

35. Release Planning ActivitiesStep 1: Update the List of WorkStep 2: Prioritise the List of WorkStep 3: Determine the Release Date and amount of work that can be completedStep 4: Select the Work to be completed in the releaseStep 5: Plan activity for 1st iteration of release

36. Release Planning Specifics

37. The Planning Game

38. Blitz Planning

39. What are the benefits and pitfalls of Iterative Development?

40. What is the role of the Customer in an Agile Project?

41. What to look for in a good Customer

42. Communication & Collaboration Stand Up Meetings Daily “Scrum” Meeting Co-located Team

43. Stand-up Meetings

44. Daily SCRUM Meeting

45. We value working software over comprehensive documentation

46. When is Documentation ImportantTo communicate information during developmentTo Specify somethingTo Permanently record somethingTo conform to regulations

47. Fundemental AdvicePrefer executable specifications over static specifications (documents)Single source informationDocument stable concepts, not speculative concepts, and thereby document as late as possible in the life cycleDocumentation is the least effective means of communication

48. Reviewing Current Documentation

49. Common Agile MethodologieseXtreme Programming (XP)SCRUMFeature Driven DevelopmentDynamic Systems Development MethodologyAdaptive Software DevelopmentLean Software Development

50. Common Theme’s

51. XP

53. SCRUM

54. Feature Driven Development

55. Crystal Clear

56. ASD

57. DSDM

58. LEANNot a specific set of practices or processesProcess, Documentation, Best practices take a back seat to goal of operational excellence.Defined by how quickly and reliably an organisation can serve its customers.

59. Seven LEAN PrinicplesEliminate WasteAmplify LearningDecide as Late as PossibleDeliver as fast as PossibleEmpower the TeamBuild in IntegritySee the Whole

60. Teams

62. Self-Organising TeamsCommunication & CollaborationAccountability & ResponsibilityLearning Teams

63. Why are Self-Organising Teams Better?

64. Engendering a Communicative and Collaborative culture

65. working in an AROculture

66. 3 domainsPERSONALACCOUNTABILITYMUTUALRESPONSIBILITYSHAREDOWNERSHIP

67. about …deliverycontrolpersonalACCOUNTABILITYcollaborationRESPONSIBILITYmutualinfluenceunitysharedsolidarityOWNERSHIP

68. initiativeleadershipDEGREE OF CONTROLWHO IS US?

69. personal accountabilityI have the control leversDefines the decisions that are ultimately mineIs the set of things my boss will hold me to and for which I am employed.‘I assure you’ rather than ‘trust me’Included in my performance agreementThis defines what is important or central in my work. I do not have to be asked to go here … it is my job to be here.Expect others to come here when your behaviour has an impact on an arena for which they are accountable, or when there is overlap with an arena for which they have shared responsibility.

70. mutual responsibilityI have the responsibility to influenceAnything that is impacted by my behaviour or my decisions is within my influenceWill include cultural and environmental dimensions, and will therefore be a significant component of my performance review conversationSomeone must be accountable, but I have the responsibility to give input, state my case, and ensure alignment with my arena of accountabilityGo here when invited or when it impacts an arena for which I am accountable.Remember that this patch may be an arena that someone else is ultimately accountable

71. shared ownershipSolidarity, who is ‘we’?The domain that falls outside the sphere of my influence, but that remains part of the whole of which I am a partAs broad as possibleAll that sits under the strategic plan, that wears our brandGo here when the brand or the ‘whole’ is threatenedBe careful because others will know more than you

72. Behaviour in an ARO culture is …Focused and targeted, not scatteredProject rather then role or position orientedDisciplinedHigh performanceCommunication isEntrepreneurial rather than beaurocraticTransparent: knowledge and power is necessarily sharedRobust and often difficult because there is lots of grey in the shared responsibility domain

73. Key vulnerabilities in an ARO culture …ACCOUNTABILITYLack of clarityExcusesREPONSIBILITYNo one accountableLack of systems thinkingOWNERSHIPfragmentation

74. Key vulnerabilities in an ARO culture … competency creep:Supplementing my accountabilities with personal competency and preferenceDisempowers those who have accountability in arena of competency creepMakes me busierIndicates a local rather than organisational view … has cascading impact on other teams/departmentsRequires trust in other’s ability to deliver according to their accountabilities