Introduction to Agile Software Development


Published on

An introductory presentation by Justin Petite explaining the benefits of an Agile approach to software development.

Published in: Software, Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to Agile Software Development

  1. 1. 1© Life Cycle Engineering 2014© Life Cycle Engineering 2014 Agile Lunch and Learn Series Introduction to Agility
  2. 2. 2© Life Cycle Engineering 2014 • 4+ years adapting and applying Agile and Scrum to SPAWAR projects • Scrum Alliance Certified Scrum Master (CSM) • Scrum Alliance Certified Scrum Professional (CSP) • PMI – Agile Certified Practitioner (PMI-ACP) @JustinPetite JUSTIN PETITE
  3. 3. 3© Life Cycle Engineering 2014 Agile. We need to be Agile. Why are we not doing Agile?
  4. 4. 4© Life Cycle Engineering 2014 AGILE An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders. Scott Ambler
  5. 5. 5© Life Cycle Engineering 2014 WHY AGILITY • Need to more effectively respond to change – Organizational needs – Market demands – Threats and opportunities • Manage evolutionary change to culture, products, and processes • Frequently and incrementally deliver value to reach a desired goal or outcome
  6. 6. 6© Life Cycle Engineering 2014 AGILITY Agility is the ability to both create and respond to change in order to profit in a turbulent business environment Agility is the ability to balance flexibility and stability Jim Highsmith Agile Project Management (2nd Edition, 2010)
  7. 7. 7© Life Cycle Engineering 2014 BENEFITS • Greater responsiveness • Measured increase in productivity • Lower costs • Managed risk through greater visibility • Increased customer satisfaction • Better overall quality • Improved team morale
  8. 8. 8© Life Cycle Engineering 2014 AGILITY
  9. 9. 9© Life Cycle Engineering 2014 MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT We are uncovering better ways of developing software by doing it 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.
  10. 10. 10© Life Cycle Engineering 2014 AGILE PRINCIPLES 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  11. 11. 11© Life Cycle Engineering 2014 AGILE PRINCIPLES 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
  12. 12. 12© Life Cycle Engineering 2014 AGILE PRACTICES
  13. 13. 13© Life Cycle Engineering 2014 Accredited to Michael Sahota & Olaf Lewitz
  14. 14. 14© Life Cycle Engineering 2014 ETHOS Plan-driven Focus on documenting & predicting outcomes Lauds deadlines & output Longer product cycle time Change is hard Value-driven Focus on understanding & executing priorities Lauds priorities & throughput Shorter product cycle time Embraces change Traditional Agile
  15. 15. 15© Life Cycle Engineering 2014 ETHOS
  16. 16. 16© Life Cycle Engineering 2014 Value (Releasable Product) Quality (Reliable, Adaptable Product) Constraints (Scope, Cost, Schedule) AGILE TRIANGLE Jim Highsmith
  17. 17. 17© Life Cycle Engineering 2014 DO’S AND DON’TS Agile methods do: • Position us to be more responsive to changing priorities • Allow better predictability of output for the foreseeable time horizon • Improve accountability • Make priorities and risk calculations more transparent
  18. 18. 18© Life Cycle Engineering 2014 DO’S AND DON’TS Agile methods don’t: • Make engineers write more lines of code per day or designers create output faster • Preclude the need to make good organizational decisions about product, priorities, and customer needs • Allow the rest of the organization to assume they think they know what lies months ahead
  19. 19. 19© Life Cycle Engineering 2014 AGILE MYTHS • “Agile is the silver bullet for our organization!” • “Agile doesn’t scale, so it can’t work for our organization!” • “No more documentation or deadlines!” • “Since we don’t do things upfront, we have no design and poor architecture!” • “With so much rework going on, nothing new, and innovative gets worked on!” • “Agile makes us faster!”
  20. 20. 20© Life Cycle Engineering 2014 ORGANIZATIONAL AGILITY • More than just “doing Agile” • Discipline of managed change through continuous inspection, evaluation, and adaptation • Tailored to the organization • Leverages Agile methods appropriately at each level: – Individual – Team – Project – Program/Portfolio – Executive
  21. 21. 21© Life Cycle Engineering 2014
  22. 22. 22© Life Cycle Engineering 2014 ITERATIVE & INCREMENTAL “Incrementing” builds a finished piece Assumes the customer has a fully formed idea of what they need Jeff Patton - 2008 know_what_i_want.html
  23. 23. 23© Life Cycle Engineering 2014 ITERATIVE & INCREMENTAL Jeff Patton - 2008 know_what_i_want.html “Iterating” builds something imperfect to validate and refine Iterating allows for less developed ideas to evolve and be refined
  24. 24. 24© Life Cycle Engineering 2014
  25. 25. 25© Life Cycle Engineering 2014 STORY MAPPING
  26. 26. 26© Life Cycle Engineering 2014 USER STORY • High-level requirement artifact: – Incremental – Negotiable – Valuable – Estimable – Small – Testable • A conversation with the stakeholder: – “As a” specific user or persona – “I want” need, feature, or functionality – “So (that)” purpose and value of delivery
  27. 27. 27© Life Cycle Engineering 2014 ACCEPTANCE CRITERIA • Flip the card over to record expectations: –User –Customer –Product Owner –Team How has the customer defined success for this story?
  28. 28. 28© Life Cycle Engineering 2014 PRODUCT BACKLOG
  29. 29. 29© Life Cycle Engineering 2014 SCRUM • Framework: – Defined Roles – Ritual Meetings – Artifacts – Terminology • Emphasis: – Value – Delivery – Open communication – Team self-organization – Stakeholder Participation
  30. 30. 30© Life Cycle Engineering 2014 SCRUM ROLES • Scrum Master – Lead, promote, facilitate, organize, and coach Scrum – Remove impediments for the team • Product Owner – Own, manage, and communicate the Product Backlog – Advocate for the customer • Scrum Team – Turn work from the backlog into a “potentially shippable” increment of working software
  31. 31. 31© Life Cycle Engineering 2014 SCRUM TIMEBOXES • Release Planning • Sprint Planning • The Sprint • Daily Scrum • Sprint Review & Demo • Sprint Retrospective
  32. 32. 32© Life Cycle Engineering 2014 PROJECT INITIATION Decompose project requirements (scope) to create the first iteration of the project schedule, roadmap, and backlog Form the cross-functional agile team(s) of individuals with the roles and skills necessary to deliver on the project’s requirements Train the team, educate the customer, and communicate expectations Get started sprinting following the standard practices to learn how to best adapt in the future · Incorporate feedback from retrospectives · Build “muscle memory” around good practices · Establish common understanding of Agile fundamentals · Agree to a cadence · Decide on initial technologies · Identify and negotiate stakeholder roles and responsibilities · Agree to the metrics by which project performance will be measured · Establish the definition of done · Set up visible progress indicators Work Breakdown Structure IMS / Roadmap Agile PM Tool User StoriesUser Stories Systems Requirements Document (SRD) Systems Requirements Document (SRD) PWS/CDRLPWS/CDRL Product OwnerProduct Owner TestersTestersDevelopersDevelopers Scrum MasterScrum Master
  33. 33. 33© Life Cycle Engineering 2014 KEEP THE AGILE CONVERSATION GOING • Software engineering practices • Agile team dynamics • Scaling up • Contracting and government • Metrics • Planning • User story writing • Testing/Quality • Retrospectives • Configuration management • Release management • Information assurance • Fostering culture • Organizational transition • Change management • Industry certifications • Management and executive sponsorship • More than software
  34. 34. 34© Life Cycle Engineering 2014 Agile Methodologies
  35. 35. 35© Life Cycle Engineering 2014
  36. 36. 36© Life Cycle Engineering 2014 THANK YOU! Please let me know how I can do better next time! @JustinPetite
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.