An Agile Development Primer


Published on

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

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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

    1. 1. Agile Software Development<br />Primer<br />
    2. 2.
    3. 3. What is Agile Development?<br />
    4. 4. &quot;The ability to move faster than those things that can harm your project…&quot; <br />
    5. 5. Agile Development is a method of building software by empowering and trusting people, acknowledgingchange as a norm, and promoting constant feedback<br />
    6. 6. Agile Software Development ... the History<br />1974 An adaptive software development process documented, <br />1991 “Rapid Application Development” published<br />1995 DSDM Framework published<br />1995 SCRUM presented at OOPSLA<br />1996 XP Practices developed on C3 project<br />1997 FDD processes designed by Jeff De Luca<br />1999 FDD described in “Java Modeling in Color with UML”<br />1999 “Extreme Programming Explained” published<br />1999 “Adaptive Software Development” published<br />2001 Crystal Light methodologies described in Cutter IT Journal, <br />2001 Agile Manifesto written<br />2003 “Lean Software Development: An Agile Toolkit for Software Development Managers” published<br />
    7. 7. Agile Software Development ... the History<br />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”<br />
    8. 8. The Manifesto for Agile Software Development<br />We are uncovering better ways of developing software by doingit and helping others do it. Through this work we have come to value:<br />Individuals and interactions over processes and tools<br />Working software over comprehensive documentation<br />Customer collaboration over contract negotiation<br />Responding to change over following a plan<br />That is, while there is value in the items on the right, we value the items on the left more<br />
    9. 9.
    10. 10.
    11. 11.
    12. 12.
    13. 13.
    14. 14.
    15. 15. Agile Principles<br />Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. <br />Welcome changing requirements, even late in development. Agile processes harness change for the customer&apos;s competitive advantage. <br />Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. <br />Business people and developers must work together daily throughout the project. <br />Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. <br />The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. <br />
    16. 16. Agile Principles<br />1. Satisfy the Customer<br />2. Welcome Change<br />3. Deliver Frequently<br />4. Work as a Team<br />5. Motivate People<br />6. Communicate Face to Face<br />
    17. 17. Agile Principles<br />
    18. 18. Agile Principles<br />
    19. 19. Agile Practices<br />
    20. 20. Agile Practices<br />Design & Programming<br />* Build Automation<br /> * Automated Deployment<br /> Continuous Integration<br /> * Simple Design<br /> Collective Ownership<br />Feature Teams<br /> * Refactoring<br /> Pair Programming<br />Testing<br />* Automated Unit Testing<br /> Acceptance Tests<br /> * Test Driven Development<br />Small Releases<br />Planning Game<br />Blitz Planning<br />Iterative Development<br />Working Without Iterations (Wall work Queue)<br />Short Iteration Cycles <br />The Task Cycle<br />Communication & Collaboration<br />Stand Up Meetings<br /> Daily “Scrum” Meeting<br /> Co-located Team<br />Documentation<br />Start of Project Documentation<br />Design Documentation<br />Other approaches<br />
    21. 21. Design & Programming<br /> *Build Automation<br /> *Automated Deployment<br /> Continuous Integration<br /> *Simple Design<br /> Collective Ownership<br />*Refactoring<br /> Pair Programming<br />
    22. 22. Build Automation<br />
    23. 23. Automated Deployment<br />
    24. 24. Continuous Integration<br />
    25. 25. Simple Design<br />
    26. 26. Collective Ownership<br />
    27. 27. Feature Teams<br />
    28. 28. Refactoring<br />
    29. 29. Pair Programming<br />
    30. 30. Testing<br /> *Automated Unit Testing<br /> Acceptance Tests<br /> *Test Driven Development<br />
    31. 31. Automated Unit Testing<br />
    32. 32. Acceptance Tests<br />
    33. 33. Test Driven Development<br />
    34. 34. Agile Management<br /> User Stories / Story Writing Workshop<br /> Release Planning Activities<br /> Iterative Development<br /> The Customer<br /> Communication & Collaboration<br /> Documentation<br />
    35. 35. Release Planning Activities<br />Step 1: Update the List of Work<br />Step 2: Prioritise the List of Work<br />Step 3: Determine the Release Date and amount of work that can be completed<br />Step 4: Select the Work to be completed in the release<br />Step 5: Plan activity for 1st iteration of release<br />
    36. 36. Release Planning Specifics<br />
    37. 37. The Planning Game<br />
    38. 38. Blitz Planning<br />
    39. 39. What are the benefits and pitfalls of Iterative Development?<br />
    40. 40. What is the role of the Customer in an Agile Project?<br />
    41. 41. What to look for in a good Customer<br />
    42. 42. Communication & Collaboration<br /> Stand Up Meetings<br /> Daily “Scrum” Meeting<br /> Co-located Team<br />
    43. 43. Stand-up Meetings<br />
    44. 44. Daily SCRUM Meeting<br />
    45. 45. We value working software over comprehensive documentation<br />
    46. 46. When is Documentation Important<br />To communicate information during development<br />To Specify something<br />To Permanently record something<br />To conform to regulations<br />
    47. 47. Fundemental Advice<br />Prefer executable specifications over static specifications (documents)<br />Single source information<br />Document stable concepts, not speculative concepts, and thereby document as late as possible in the life cycle<br />Documentation is the least effective means of communication<br />
    48. 48. Reviewing Current Documentation<br />
    49. 49. Common Agile Methodologies<br />eXtreme Programming (XP)<br />SCRUM<br />Feature Driven Development<br />Dynamic Systems Development Methodology<br />Adaptive Software Development<br />Lean Software Development<br />
    50. 50. Common Theme’s<br />
    51. 51. XP<br />
    52. 52.
    53. 53. SCRUM<br />
    54. 54. Feature Driven Development<br />
    55. 55. Crystal Clear<br />
    56. 56. ASD<br />
    57. 57. DSDM<br />
    58. 58. LEAN<br />Not a specific set of practices or processes<br />Process, Documentation, Best practices take a back seat to goal of operational excellence.<br />Defined by how quickly and reliably an organisation can serve its customers.<br />
    59. 59. Seven LEAN Prinicples<br />Eliminate Waste<br />Amplify Learning<br />Decide as Late as Possible<br />Deliver as fast as Possible<br />Empower the Team<br />Build in Integrity<br />See the Whole<br />
    60. 60. Teams<br />
    61. 61.
    62. 62. Self-Organising Teams<br />Communication & Collaboration<br />Accountability & Responsibility<br />Learning Teams<br />
    63. 63. Why are Self-Organising Teams Better?<br />
    64. 64. Engendering a Communicative and Collaborative culture<br />
    65. 65. working in an AROculture<br />
    66. 66. 3 domains<br />PERSONAL<br />ACCOUNTABILITY<br />MUTUAL<br />RESPONSIBILITY<br />SHARED<br />OWNERSHIP<br />
    67. 67. about …<br />delivery<br />control<br />personal<br />ACCOUNTABILITY<br />collaboration<br />RESPONSIBILITY<br />mutual<br />influence<br />unity<br />shared<br />solidarity<br />OWNERSHIP<br />
    68. 68. initiative<br />leadership<br />DEGREE OF CONTROL<br />WHO IS US?<br />
    69. 69. personal accountability<br />I have the control levers<br />Defines the decisions that are ultimately mine<br />Is the set of things my boss will hold me to and for which I am employed.<br />‘I assure you’ rather than ‘trust me’<br />Included in my performance agreement<br />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.<br />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.<br />
    70. 70. mutual responsibility<br />I have the responsibility to influence<br />Anything that is impacted by my behaviour or my decisions is within my influence<br />Will include cultural and environmental dimensions, and will therefore be a significant component of my performance review conversation<br />Someone must be accountable, but I have the responsibility to give input, state my case, and ensure alignment with my arena of accountability<br />Go here when invited or when it impacts an arena for which I am accountable.<br />Remember that this patch may be an arena that someone else is ultimately accountable<br />
    71. 71. shared ownership<br />Solidarity, who is ‘we’?<br />The domain that falls outside the sphere of my influence, but that remains part of the whole of which I am a part<br />As broad as possible<br />All that sits under the strategic plan, that wears our brand<br />Go here when the brand or the ‘whole’ is threatened<br />Be careful because others will know more than you<br />
    72. 72. Behaviour in an ARO culture is …<br />Focused and targeted, not scattered<br />Project rather then role or position oriented<br />Disciplined<br />High performance<br />Communication is<br />Entrepreneurial rather than beaurocratic<br />Transparent: knowledge and power is necessarily shared<br />Robust and often difficult because there is lots of grey in the shared responsibility domain<br />
    73. 73. Key vulnerabilities in an ARO culture …<br />ACCOUNTABILITY<br />Lack of clarity<br />Excuses<br />REPONSIBILITY<br />No one accountable<br />Lack of systems thinking<br />OWNERSHIP<br />fragmentation<br />
    74. 74. Key vulnerabilities in an ARO culture …<br /> competency creep:<br />Supplementing my accountabilities with personal competency and preference<br />Disempowers those who have accountability in arena of competency creep<br />Makes me busier<br />Indicates a local rather than organisational view … has cascading impact on other teams/departments<br />Requires trust in other’s ability to deliver according to their accountabilities<br />
    75. 75. Organisational Learning<br />Recruitment<br />Rewards & Incentives<br />Organisational Change<br />Organisational Learning<br />Team Change<br />Team Learning<br />Tolerance of Failure<br />Empowerment<br />Management Time<br />Individual Learning<br />Slack – time, resources, opportunity<br />Trust & Honesty<br />