Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fundamentals of Agile Methodologies - Part I

This presentation has been compiled using material available in public domain. Copyrights of the owners and sources of the material used has been duly acknowledged.

  • Login to see the comments

Fundamentals of Agile Methodologies - Part I

  1. 1. Fundamentals of Agile Methodologies - I Compiled By: Dr. Gopinath Ramakrishnan Agile Coach & Process Transformation Specialist Contact Information: e-mail: gopi@rgopinath.com LinkedIn: www.linkedin.com/in/gopinathr Twitter: @gpnth Website: www.rgopinath.com
  2. 2. Note The contents of the following slides are compiled from public domain works of several persons/ organizations. Their contribution is gratefully acknowledged their copyrights and trademarks are duly recognized.
  3. 3. Acknowledgements • Agile 42: www.agile42.com • Agile Alliance: www.agilealliance.org • Agile Transformation Inc: www.agiletransformation.com • Dzone: www.dzone.com • Gear Stream: www.gearstream.com • Henrik Kniberg: www.crisp.se/henrik.kniberg • Jeff Sutherland : scrum.jeffsutherland.com • Ken Schwaber: kenschwaber.wordpress.com/ • Kent Beck: www.threeriversinstitute.org • Mike Cohn: www.mountaingoatsoftware.com • Pete Deemer: www.goodagile,com • Roman Pichler: www.romanpichler.com • Ron Jeffries: xprogramming.com • Scrum Alliance: www.scrumalliance.org • Scrum.org: www.scrum.org • Wikipedia: www.wikipedia.org
  4. 4. Contents 1. Overview of Agile  Limitations of Traditional Software Development  Origin of Agile Methodologies  Agile Manifesto, Principles & Practices  Agile Vs Traditional Methods  So What is Agile ? 2. Overview of Scrum  Empirical Process Control  Scrum Lifecycle & Framework  Scrum Roles  3 Pillars of Scrum  Transparency , Inspection and Adaptation 3. Product Vision and Product Roadmap  Five Levels of Planning  Product Vision – Example & Template  Product Roadmap – Example & Template
  5. 5. Contents (contd..) 4. Release Planning  Product Backlog – Examples and Attributes  Product Backlog Creation Steps  User Stories – Writing, INVEST criteria, Splitting Techniques  User Story Estimation – Story Points, Planning Poker  Product Backlog Prioritization and Ordering  Release Plan Creation
  6. 6. 1: Overview of Agile Limitations of Traditional Software Development Origin of Agile Methodologies Agile Manifesto, Principles & Practices Agile Vs Traditional Methods So What is Agile ?
  7. 7. Software Development - 1970s • Cowboy Coding (Adhoc Code & Fix approach)  Project Failures • Computing Time Costly  Failure Not an Option • Birth of Software Engineering Discipline (c) Dr. Gopinath Ramakrishnan, 2015
  8. 8. Software Engineering Discipline • Software Development Lifecycle (SDLC) models – Waterfall, V-Model, Spiral, Incremental, Iterative • Standards & Process Frameworks – DOD Standards, CMM, ISO, SPICE (c) Dr. Gopinath Ramakrishnan, 2015
  9. 9. Traditional SDLC– Waterfall Model Source : http://commons.wikimedia.org/wiki/File:Waterfall_model.svg SDLC – Software Development Life Cycle
  10. 10. Traditional SDLC - Limitations • Change Management difficult • Heavy Documentation not read and understood • Big Upfront Planning cannot predict uncertainties • Hand-offs foster adversarial relationship • Late Availability of Working Software leads to delayed customer feedback (c) Dr. Gopinath Ramakrishnan, 2015
  11. 11. Business Scenario – 1990s onwards S ource : http://www.stratabridge.com/wp-content/uploads/2012/02/VUCA-Definition.jpg
  12. 12. Standish Group – CHAOS Report 1994 • 84 % Projects Challenged or Failures – Only 16 % Projects Successful • Top Reasons for Failure – Incomplete Requirements – Lack of User Involvement – Lack of Resources – Unrealistic Expectations – Lack of Executive Support (c) Dr. Gopinath Ramakrishnan, 2015
  13. 13. Origin of Agile Methodologies
  14. 14. Emergence of Lightweight Methodologies • 1992 – Crystal Methods • 1994 – DSDM (Dynamic Systems Development Method) • 1995 – Scrum • 1997 – FDD (Feature Driven Development) • 1999 – ASD (Adaptive Software Development), XP (Extreme Programming) (c) Dr. Gopinath Ramakrishnan, 2015
  15. 15. Feb 11-13, 2001 - 17 Thought Leaders @ Snowbird Ski Resort, Utah http://setandbma.wordpress.com/2012/03/23/agile-history
  16. 16. Agile Manifesto – Values & Principles
  17. 17. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others to 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 Alliance Members http://www.agilemanifesto.org/
  18. 18. Source :http://cdn.dzone.com/static/images/mails/agileposter-v3a.jpg
  19. 19. Source: http://www.lynnecazaly.com.au/the-visual-agile-manifesto/
  20. 20. 12 Agile Principles 1. Customer Satisfaction 2. Welcome Changing Requirements 3. Deliver Working Software Frequently 4. Business People and Developers to Work Together 5. Motivated Individuals 6. Face-to-Face Conversations 7. Working Software is the Primary Measure of Progress 8. Sustained Pace of Development 9. Technical Excellence and Good Design 10. Simplicity is Essential 11. Self-organizing Team 12. Regular Tunings and Adjustments of Team Behavior
  21. 21. Agile Vs Traditional Methods
  22. 22. Agile Vs Traditional Methods Traditional Method Agile Method Changes Resisted and Controlled Welcomed and Adapted to Contracts Binding Flexible Customer Interaction During selected milestones Continuous Delivery One-time Iterative and Incremental Orientation Process People Process Heavyweight Lightweight Requirements Architecture & Design Defined Upfront Evolves Roles More Less Success Criteria Conformance to the Requirements Business value delivered to the customer (c) Dr. Gopinath Ramakrishnan, 2015
  23. 23. Waterfall Projects Vs Agile Projects
  24. 24. Project Success Scenario in 2009 • Standish Group - CHAOS Report 1994 – Only 16 % Projects Successful • Standish Group - CHAOS Report 2009 – 32 % Projects Succeeded • Project Success Rate doubled in 15 years • Coincides with the Agile emergence • Still a long way to go ! (c) Dr. Gopinath Ramakrishnan, 2015
  25. 25. Agile projects - 3 times more successful Source : http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times- more-often-than-waterfall
  26. 26. Agile Methodologies - Characteristics • Business Value Focus • Iterative • Incremental • Time-boxed • Feedback (c) Dr. Gopinath Ramakrishnan, 2015
  27. 27. Agile Methodologies Source: http://www.slideshare.net/RichardPDoerer/what-isagile-henrik-kniberg-august-20-2013
  28. 28. Agile is…. • A set of Engineering Practices that – enable rapid delivery • Project Management that – encourages frequent inspection and adaptation • A Business Approach that – aligns development with customer needs and company goals • Leadership that encourages – teamwork, self-organization and accountability • A set of Values and Principles that should be – internalized by every Agile Practitioner (c) Dr. Gopinath Ramakrishnan, 2015
  29. 29. 2: Overview of Scrum Empirical Process Control Scrum Lifecycle & Framework Scrum Roles 3 Pillars of Scrum Transparency , Inspection and Adaptation
  30. 30. Empirical Process Control
  31. 31. Source: http://www.slideshare.net/gamsjo/empirical-processcontrol Assembly Line Manufacturing Research and Development
  32. 32. ource: http://www.slideshare.net/gamsjo/empirical-processcontrol
  33. 33. Empirical Process Control • Knowledge comes from experience • Making decisions based on what is known. • Iterative & Incremental approach – to optimize predictability and control risk. • Empirical Process Control Theory is the foundation of Scrum (c) Dr. Gopinath Ramakrishnan, 2015
  34. 34. Scrum Lifecycle
  35. 35. Scrum Cancel Gift wrap Return Sprint 2-4 weeks Return Sprint goal Sprint backlog Potentially shippable product increment Product backlog CouponsGift wrap Coupons Cancel 24 hours
  36. 36. Putting it all together Image available at www.mountaingoatsoftware.com/scrum
  37. 37. Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Requirements Design Code Test
  38. 38. No changes during a sprint • Plan sprint durations around how long you can commit to keeping change out of the sprint Change
  39. 39. Scrum Framework
  40. 40. Scrum framework •Product owner •ScrumMaster • Development Team Roles •Sprint planning •Daily Scrum •Sprint review •Sprint retrospective Ceremonies •Product backlog •Sprint backlog •Increment Artifacts
  41. 41. Scrum Roles
  42. 42. Scrum framework •Sprint planning •Daily scrum meeting •Sprint review •Sprint retrospective Ceremonies •Product backlog •Sprint backlog •Increment Artifacts •Product owner •ScrumMaster • Development Team Roles
  43. 43. Product owner • Define the features of the product • Make scope vs schedule decisions • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results
  44. 44. The ScrumMaster • Responsible for enacting Scrum values and practices • Removes impediments • Coaches the team to their best possible performance • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences
  45. 45. The Development Team • Typically 5-9 people • Cross-functional: – Programmers, testers, user experience designers, etc. • Members should be full-time – May be exceptions (e.g., database administrator) • Teams are self-organizing – Ideally, no titles but rarely a possibility • Membership should change only between sprints
  46. 46. Source: http://www.adventureswithagile.com/empiricism-and-complexity-in-software-development/
  47. 47. Transparency • Significant aspects of the process visible – to those responsible for the outcome • Aspects be defined by a common standard – to share a common understanding • For e.g. – A common language referring to the process – A common definition of “Done”1 (c) Dr. Gopinath Ramakrishnan, 2015
  48. 48. Inspection • Frequently inspect to detect undesirable variances – Not so frequent to get in the way of the work – Most beneficial when diligently performed by skilled inspectors at the point of work. (c) Dr. Gopinath Ramakrishnan, 2015
  49. 49. Adaptation • Adjustment of the process or the material being processed if – one or more aspects of a process deviate outside acceptable limits, and – that the resulting product will be unacceptable • Made as soon as possible – to minimize further deviation. • Four formal opportunities in Scrum for inspection and adaptation – Sprint Planning Meeting , Daily Scrum , Sprint Review Meeting , Sprint Retrospective (c) Dr. Gopinath Ramakrishnan, 2015
  50. 50. Scrum - Summary © 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde http://www.goodagile.com/scrumprimer/scrumprimer.pdf
  51. 51. 3: Product Vision and Roadmap Five Levels of Planning Product Vision – Example & Template Product Roadmap – Example & Template
  52. 52. Product Vision and Product Roadmap
  53. 53. Product Vision • Visualizes the Released Product • Guides Product Development • Overarching Goal that Everyone Shares (c) Dr. Gopinath Ramakrishnan, 2015
  54. 54. Product Vision (contd..) • Who is the target customer? • What customer needs will it solve? • What are its critical attributes? • What are its unique selling points? (c) Dr. Gopinath Ramakrishnan, 2015
  55. 55. Example- Silicon Graphics Workstations For movie producers and others who depend heavily on post-production special effects the Silicon Graphics is a range of workstations That have capabilities to integrate digital fantasies with actual film footage. Unlike other general purpose computer workstations, Our products are a no-compromise commitment to meeting film makers' post-production needs [Adapted from Geoffery Moore’s example in the book Crossing the Chasm] (c) Dr. Gopinath Ramakrishnan, 2015
  56. 56. Product Vision - Template For <target customer> Who <statement of the need or opportunity> The <product name> is a <product category> That <key benefit, compelling reason to buy> Unlike <primary competitive alternative> Our product <statement of primary differentiation> [Geoffery Moore’s in the book Crossing the Chasm] (c) Dr. Gopinath Ramakrishnan, 2015
  57. 57. Product Roadmap • High-level strategic plan providing longer- term outlook • Helps to secure funds • Sets expectations • Aligns stakeholders • Facilitates prioritization & coordination • Provides Reassurance to the Customers (c) Dr. Gopinath Ramakrishnan, 2015
  58. 58. Product Roadmap (contd..) • Names of the releases planned • Dates/ timeframes of releases • Goals of each release • Key features of each release • Release Success Criteria (c) Dr. Gopinath Ramakrishnan, 2015
  59. 59. Example – Product Roadmap of a Dance Game • A dance game for girls aged eight to 12 years. • Fun and educational • Allows the players to – modify the characters – change the music – dance with remote players – choreograph new dances.
  60. 60. http://www.romanpichler.com/tools/product- roadmap/
  61. 61. Example – Product Roadmap of a Dance Game (contd..) http://www.slideshare.net/romanpichler/agile-product-roadmap-tutorial
  62. 62. 4: Release Planning Product Backlog – Examples and Attributes Product Backlog Creation Steps User Stories – Writing, INVEST criteria, Splitting Techniques User Story Estimation – Story Points, Planning Poker Product Backlog Prioritization and Ordering Release Plan Creation
  63. 63. Product Backlog
  64. 64. Product Backlog • A Single, Transparent and Official List of Requirements or Pending Activities • Maintained by Product Owner • Continuously Evolves throughout the product lifecycle – depending on changes in business requirements, market conditions, or technology (c) Dr. Gopinath Ramakrishnan, 2015
  65. 65. Product Backlog Items (PBIs) • Customer-centric Features – Epics and User Stories • Technical Improvements – Refactoring, Performance improvements • Research Work (aka Spikes) – the ones needed for implementing features • Known Defects – only if they are few in numbers (c) Dr. Gopinath Ramakrishnan, 2015
  66. 66. PBIs - Examples Source : http://www.goodagile.com/scrumprimer/scrumprimer.pdf
  67. 67. Product Backlog – Attributes Detailed Appropriately Estimated Emergent Prioritized Source: Agile Product Management, Roman Pichler
  68. 68. Product Backlog Creation Steps • Write User Stories and other PBIs • Prioritize/Order based on business value • Split/Slice the Epics (Big PBI) • Estimate PBI size (relative estimation) • Evaluate risks and dependencies • Determine the order of development (c) Dr. Gopinath Ramakrishnan, 2015
  69. 69. Product Backlog Creation - User Story Writing
  70. 70. Epic • Large Feature/Functionality in the Product Roadmap • Too big to be DONE in one sprint • To be broken down into smaller features/functionalities (User Stories) (c) Dr. Gopinath Ramakrishnan, 2015
  71. 71. User Story • A smallest piece of Functionality from the User Perspective that can be DONE in one sprint – DONE means potentially releasable condition • Has Business Value • Description has 3 Parts – User (Who ?) – Functionality (What?) – Business Justification (Why ?) • Must be accompanied by an Acceptance Criteria (c) Dr. Gopinath Ramakrishnan, 2015
  72. 72. User Story Acceptance Criteria • Conditions that a story must satisfy to be accepted by PO • A set of statements, each with a clear pass/fail result, that specify both functional and non- functional requirements (c) Dr. Gopinath Ramakrishnan, 2015
  73. 73. The 3 Cs of a User Story
  74. 74. User Roles • Recognize and Explicitly Identify Multiple User Roles • Avoid the word “User” in the Stories • Don’t Write Stories from a single User Role Perspective
  75. 75. User story format As a <User> I can <Functionality> so that <Business Justification> (c) Dr. Gopinath Ramakrishnan, 2015
  76. 76. User Stories - Samples
  77. 77. User Stories – Acceptance Criteria • An Example
  78. 78. User Story – Review Criteria Source: www.gearstream.com
  79. 79. User Stories - INVEST • Independent – Should be possible to implement in any order – Should not overlap each other – Example Image Source: www.gearstream.com
  80. 80. User Stories – INVEST (contd..) • Negotiable – Should be descriptive, not prescriptive – Not exhaustive – Should stimulate conversation between the team and the Product Owner or Customer – Example • As a book-lover, I want to download a new book so that I can save time going to a bookshop (c) Dr. Gopinath Ramakrishnan, 2015
  81. 81. User Stories – INVEST (contd..) • Valuable to Users or Customers – Should have clear external value Does not describe the value to the customer Written from developer perspective Image Source: www.gearstream.com
  82. 82. User Stories – INVEST (contd..) • Estimatable – Should be descriptive enough to be estimated • Small – Should require no more than 4 days and no less than ½ day of work to implement • Testable – Should be able to prove that it is truly DONE – Acceptance Criteria is defined (c) Dr. Gopinath Ramakrishnan, 2015
  83. 83. INVEST - Summary Source: http://www.slideshare.net/thomasjeffreyandersontwin/lean-agile-stack-training-kanban-scrum-user-stories
  84. 84. Good Acceptance Criteria • State an intent not a solution – e.g. “The user can choose an account” rather than “The user can select the account from a drop-down” • Are independent of implementation – discuss WHAT is expected, and not HOW the functionality will be implemented • Are relatively high level – more details (if needed) are captured in team member’s internal notes or in automated acceptance tests (c) Dr. Gopinath Ramakrishnan, 2015
  85. 85. Product Backlog Creation Steps • Write User Stories and other PBIs • Prioritize/Order based on business value • Split/Slice the Epics (Big PBI) • Estimate PBI size (relative estimation) • Evaluate risks and dependencies • Determine the order of development (c) Dr. Gopinath Ramakrishnan, 2015
  86. 86. Product Backlog Creation - User Story Splitting/Slicing
  87. 87. Why Split User Stories ? • To create smaller stories that are potentially shippable by the end of a sprint • More focus • Flexibility to reconfigure and adapt to new discoveries and changes • More feedback opportunities (c) Dr. Gopinath Ramakrishnan, 2015
  88. 88. User Story Splitting - Horizontal http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake
  89. 89. User Story Splitting - Vertical http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake
  90. 90. User Story – Basis of Various Splitting Techniques • Requirements Options – Ellen Gottesdiener & Mary Gorman • Incremental build up of quality – Gerard Mezzaros and Jeff Patton • Nine Patterns of Functional Complexity – Richard Lawrence • Twenty Ways based on Big Picture, User Experience, “illities”, and Features – Bill Wake The above techniques have overlaps and are not mutually exclusive (c) Dr. Gopinath Ramakrishnan, 2015
  91. 91. User Story Splitting – Requirements Options Source: “Slicing Requirements for Agile Success”, Ellen Gottesdiener and Mary Gorman , Better Software , July/August 2010
  92. 92. © Jeff Patton, all rights reserved, www.AgileProductDesign.com User Story Splitting – Incremental build up of quality • Bare Necessity – For the feature to be minimally demonstrable – but not releasable, what is the minimal functionality – Example: A form with only necessary fields and no validation • Capability & Flexibility – What would add the ability to perform the user task in different ways? Adding in sub tasks that are optionally performed? – Example: a form with optional fields, date lookup tools, input translation on dates • Safety – What would make this feature safer for me to use? For both the user, and for the business paying for the software? – Example: input validation, enforcement of business rules such as credit card validation • Usability, Performance, Jazziness – What would make this feature easier to use? More desirable to use? Faster to use? – Example: auto-completion, jazzy visual design, speed keys •Adapted from Gerard Meszaros’ “Storyotypes” in http://www.agileproductdesign.com/downloads/patton_user_story_mapping.ppt(c) Dr. Gopinath Ramakrishnan, 2015
  93. 93. User Story Splitting – Functional Complexity Patterns • Workflow steps • Business rule variations • Major effort • Simple/complex • Variations in data • Data display /entry methods • Defer performance • Operations (e.g. CRUD) • ‘Spike’ it Source: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting- user-stories
  94. 94. User Story Splitting – Twenty Ways Source :Bill Wake, http://xp123.com/articles/twenty-ways-to-split-stories
  95. 95. Product Backlog Creation - User Story Estimation
  96. 96. User Story Estimation • Estimation Unit – Story Point (SP) • Basis of Estimation – Size, – Complexity – Uncertainty – Effort • Estimation Scale – 1, 2, 3, 5, 8, 13, 20 ,40, 100 • Relative Estimation • Collaborative & Consensus Based (c) Dr. Gopinath Ramakrishnan, 2015
  97. 97. Estimation Techniques • Planning Poker • Affinity Sizing • Complexity Buckets (c) Dr. Gopinath Ramakrishnan, 2015
  98. 98. Planning Poker • Estimation from Multiple Perspectives • Discussion Oriented • Fun Image Source : https://www.crisp.se/bocker-och-produkter/planning-poker
  99. 99. Affinity Sizing/Triangulation of Estimates For e.g. An User Story of 2 SPs must be roughly twice as big/complex as an User Story of 1 SP and less than half as big/complex as an User Story of 5 SP Source: Agile Estimation and Planning by Mike Cohn
  100. 100. Complexity Buckets
  101. 101. Story Point Estimates - Benefits • A pure measure of size – Easier to provide relative estimates • Estimates do not change – when team’s understanding of the technology and the domain improves • Estimating process help in driving cross- functional behavior – During estimation all specialists discuss and arrive at a single story point estimate (c) Dr. Gopinath Ramakrishnan, 2015
  102. 102. Product Backlog Creation – Prioritization / Ordering
  103. 103. Product Backlog – Prioritization/Development Order Criteria • Business Value • Risks • Size/Complexity • Infrastructure needs • Dependencies • Return on Investment • Grouping based on ease of development
  104. 104. Release Plan Creation
  105. 105. Release Plan • Maps Major Features to Specific Releases • More Detailed than Product Roadmap, Less Detailed than Sprint (Iteration) Plan • Continuously updated based on rate of progress (c) Dr. Gopinath Ramakrishnan, 2015
  106. 106. Velocity • Measure of Rate of Progress • Sum of Story Points of the Stories DONE in an iteration • Story Points of the Work-in-Progress Stories not counted • Useful for Forecasting – Final Delivery Dates for a Fixed Scope of Features – Features that can be delivered on a Fixed Date (c) Dr. Gopinath Ramakrishnan, 2015
  107. 107. Estimating Velocity • Use Past Data • Run an Iteration and Use the Velocity of that Iteration • Take a Guess (c) Dr. Gopinath Ramakrishnan, 2015
  108. 108. Release Planning Steps • Select Iteration Length : 2-4 weeks • Estimate Iteration Velocity • Allocate Stories to Iterations as per Priority and Velocity (c) Dr. Gopinath Ramakrishnan, 2015
  109. 109. Release Plan – An Example Source: www.gearstream.com

×