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.
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 History 1974 An adaptive software development process documented, 1991 “Rapid Application Development” published 1995 DSDM Framework published 1995 SCRUM presented at OOPSLA 1996 XP Practices developed on C3 project 1997 FDD processes designed by Jeff De Luca 1999 FDD described in “Java Modeling in Color with UML” 1999 “Extreme Programming Explained” published 1999 “Adaptive Software Development” published 2001 Crystal Light methodologies described in Cutter IT Journal, 2001 Agile Manifesto written 2003 “Lean Software Development: An Agile Toolkit for Software Development Managers” published
7. Agile Software Development ... the History Kent 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 Development We 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 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
9.
10.
11.
12.
13.
14.
15. Agile Principles Our 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 Principles 1. Satisfy the Customer 2. Welcome Change 3. Deliver Frequently 4. Work as a Team 5. Motivate People 6. Communicate Face to Face
20. Agile Practices Design & Programming * Build Automation * Automated Deployment Continuous Integration * Simple Design Collective Ownership Feature Teams * Refactoring Pair Programming Testing * Automated Unit Testing Acceptance Tests * Test Driven Development Small Releases Planning Game Blitz Planning Iterative Development Working Without Iterations (Wall work Queue) Short Iteration Cycles The Task Cycle Communication & Collaboration Stand Up Meetings Daily “Scrum” Meeting Co-located Team Documentation Start of Project Documentation Design Documentation Other approaches
34. Agile Management User Stories / Story Writing Workshop Release Planning Activities Iterative Development The Customer Communication & Collaboration Documentation
35. Release Planning Activities Step 1: Update the List of Work Step 2: Prioritise the List of Work Step 3: Determine the Release Date and amount of work that can be completed Step 4: Select the Work to be completed in the release Step 5: Plan activity for 1st iteration of release
46. When is Documentation Important To communicate information during development To Specify something To Permanently record something To conform to regulations
47. Fundemental Advice Prefer executable specifications over static specifications (documents) Single source information Document stable concepts, not speculative concepts, and thereby document as late as possible in the life cycle Documentation is the least effective means of communication
49. Common Agile Methodologies eXtreme Programming (XP) SCRUM Feature Driven Development Dynamic Systems Development Methodology Adaptive Software Development Lean Software Development
58. LEAN Not a specific set of practices or processes Process, 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 Prinicples Eliminate Waste Amplify Learning Decide as Late as Possible Deliver as fast as Possible Empower the Team Build in Integrity See the Whole
69. personal accountability I have the control levers Defines the decisions that are ultimately mine Is 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 agreement This 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 responsibility I have the responsibility to influence Anything that is impacted by my behaviour or my decisions is within my influence Will include cultural and environmental dimensions, and will therefore be a significant component of my performance review conversation Someone must be accountable, but I have the responsibility to give input, state my case, and ensure alignment with my arena of accountability Go 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 ownership Solidarity, 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 part As broad as possible All that sits under the strategic plan, that wears our brand Go here when the brand or the ‘whole’ is threatened Be careful because others will know more than you
72. Behaviour in an ARO culture is … Focused and targeted, not scattered Project rather then role or position oriented Disciplined High performance Communication is Entrepreneurial rather than beaurocratic Transparent: knowledge and power is necessarily shared Robust and often difficult because there is lots of grey in the shared responsibility domain
73. Key vulnerabilities in an ARO culture … ACCOUNTABILITY Lack of clarity Excuses REPONSIBILITY No one accountable Lack of systems thinking OWNERSHIP fragmentation
74. Key vulnerabilities in an ARO culture … competency creep: Supplementing my accountabilities with personal competency and preference Disempowers those who have accountability in arena of competency creep Makes me busier Indicates a local rather than organisational view … has cascading impact on other teams/departments Requires trust in other’s ability to deliver according to their accountabilities
75. Organisational Learning Recruitment Rewards & Incentives Organisational Change Organisational Learning Team Change Team Learning Tolerance of Failure Empowerment Management Time Individual Learning Slack – time, resources, opportunity Trust & Honesty
Hinweis der Redaktion
Workshop Question. 15 minutes discussion around small tables then group feedback
Agile is not a new concept. 1974 Edwards discussed the flaws in the waterfall methodology.Evolution through the 90’s (following RAD in the 80’s) of various approaches to structure a software development project to deliver results.