An Agile Development Primer
Upcoming SlideShare
Loading in...5

An Agile Development Primer



An overview of the Agile Manifesto and the principles and practices that define Agile software development. A comparison of Agile Development methodologies and an organisational culture that supports ...

An overview of the Agile Manifesto and the principles and practices that define Agile software development. A comparison of Agile Development methodologies and an organisational culture that supports them



Total Views
Views on SlideShare
Embed Views



1 Embed 11 11



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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.

An Agile Development Primer An Agile Development Primer Presentation Transcript

  • Agile Software Development
  • What is Agile Development?
  • "The ability to move faster than those things that can harm your project…"
  • Agile Development is a method of building software by empowering and trusting people, acknowledgingchange as a norm, and promoting constant feedback
  • 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
  • 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”
  • 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
  • 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.
  • 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
  • Agile Principles
  • Agile Principles
  • Agile Practices
  • Agile Practices
    Design & Programming
    * Build Automation
    * Automated Deployment
    Continuous Integration
    * Simple Design
    Collective Ownership
    Feature Teams
    * Refactoring
    Pair Programming
    * 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
    Start of Project Documentation
    Design Documentation
    Other approaches
  • Design & Programming
    *Build Automation
    *Automated Deployment
    Continuous Integration
    *Simple Design
    Collective Ownership
    Pair 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
  • Automated Unit Testing
  • Acceptance Tests
  • Test Driven Development
  • Agile Management
    User Stories / Story Writing Workshop
    Release Planning Activities
    Iterative Development
    The Customer
    Communication & Collaboration
  • 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
  • Release Planning Specifics
  • The Planning Game
  • Blitz Planning
  • What are the benefits and pitfalls of Iterative Development?
  • What is the role of the Customer in an Agile Project?
  • What to look for in a good Customer
  • Communication & Collaboration
    Stand Up Meetings
    Daily “Scrum” Meeting
    Co-located Team
  • Stand-up Meetings
  • Daily SCRUM Meeting
  • We value working software over comprehensive documentation
  • When is Documentation Important
    To communicate information during development
    To Specify something
    To Permanently record something
    To conform to regulations
  • 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
  • Reviewing Current Documentation
  • Common Agile Methodologies
    eXtreme Programming (XP)
    Feature Driven Development
    Dynamic Systems Development Methodology
    Adaptive Software Development
    Lean Software Development
  • Common Theme’s
  • XP
  • Feature Driven Development
  • Crystal Clear
  • ASD
  • DSDM
  • 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.
  • 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
  • Teams
  • Self-Organising Teams
    Communication & Collaboration
    Accountability & Responsibility
    Learning Teams
  • Why are Self-Organising Teams Better?
  • Engendering a Communicative and Collaborative culture
  • working in an AROculture
  • 3 domains
  • about …
  • initiative
    WHO IS US?
  • 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.
  • 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
  • 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
  • Behaviour in an ARO culture is …
    Focused and targeted, not scattered
    Project rather then role or position oriented
    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
  • Key vulnerabilities in an ARO culture …
    Lack of clarity
    No one accountable
    Lack of systems thinking
  • 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
  • Organisational Learning
    Rewards & Incentives
    Organisational Change
    Organisational Learning
    Team Change
    Team Learning
    Tolerance of Failure
    Management Time
    Individual Learning
    Slack – time, resources, opportunity
    Trust & Honesty