Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Introduction to Agile - Scrum, Kanban, and everything in between

•Download as PPTX, PDF•
•
Pravin Kumar Singh, PMP, PSM
Pravin Kumar Singh, PMP, PSM

This document provides an introduction to Agile project management frameworks like Scrum and Kanban. It discusses the limitations of traditional waterfall project management and how Agile aims to address these issues through iterative development, collaboration, and flexibility. Key aspects of Scrum like roles, events, artifacts, estimation and user stories are explained. Kanban concepts such as visualizing workflow, limiting work in progress, and managing flow are also covered. The document recommends resources for learning more about Agile, Scrum, Kanban and hybrid approaches.

1 of 52
Introduction to Agile Scrum, Kanban, and everything in between Pravin Singh
The world before Agile
The world before Agile Safeguard – Anti-Ballistic Missile Defense System • 1969 – 1975, 5407 person years • Cost: $25 Billion (not adjusted) • The project was delivered according to specifications
The world before Agile Safeguard – Anti-Ballistic Missile Defense System • 1969 – 1975, 5407 person years • Cost: $25 Billion (not adjusted) • The project was delivered according to specifications Operational for 133 days, project terminated in 1978 By the time the 6 year anti-missile system project was completed, the new missiles were faster than the anti-missile missiles.
Then came Agile • Iterative, Incremental, based on Inspect & Adapt • Focuses on fail-fast • Very Lightweight – focused on working software, not on processes • Requirements evolve over time • So does Design Humphrey’s Law: Users will never know what they want until they see it in production.
The Iron Triangle - Waterfall Scope Schedule Cost Plan Driven
The Iron Triangle - Agile Scope Schedule Cost Value Driven
Delivery Verification Work Breakdown - Agile Requirements Design Implementation Feature1 Feature2 Feature3 Feature4 Feature5 Feature6 Feature7 Feature8
Painting the Mona Lisa - Waterfall
Painting the Mona Lisa - Agile
Why Agile • Helps handle changing requirements and priorities • Lowers cost of change • Provides better visibility into project progress • Reduces risk • Maximizes Return on Investment (business value prioritization) • Delivers business value early and often
The Agile Manifesto 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.
Agile Values and Principles • Our highest priority is to satisfy the customer through early and continuous delivery. • Welcome changing requirements. Agile processes harness change for the customer's competitive advantage. • Business people and engineers 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 team is face-to-face conversation.
Agile Values and Principles • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, engineers, and users should be able to maintain a constant pace indefinitely. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self- organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Flavors of Agile Agile Scrum Kanban XP FDD Crystal
When Agile works best • Unclear/evolving requirements • Changing priorities • Customer availability • Collocated team • Flexible funding (like Time & Material contracts)
When Agile does NOT work so well • Firm Fixed Price (all-or-nothing) contracts • Different vendors for different phases • Unavailability of customer • Stable, upfront requirements
Game Time☺ All talk and no play makes session a dull affair
Scrum
Scrum in a nutshell
Scrum Roles Product Owner • Voice of customer • Owner of the Product Backlog • Prioritizes the items to best achieve goals and missions • Optimizes the work of the development team
Scrum Roles Development Team • Cross-functional • Self-organizing, self-managed • Has no sub-teams and no titles (other than team member) • Generally of size 3-9 members
Scrum Roles Scrum Master • A servant-leader for the team • Removes impediments • Facilitates Scrum events • Helps Product Owner maintain the backlog • Coaches and guides
Scrum Events • The Sprint • Sprint Planning • Daily Scrum (Standup) • Sprint Review (Demo) • Retrospective
Scrum Artifacts Product Backlog • Ordered list of requirements • A living document (is never complete) • Per Product, not per Team • Owned by the Product Owner Sprint Backlog • Items selected for the Sprint • Only team can change it during Sprint
Estimation& Velocity • Hours/ Days • T-shirt sizes • Story Points  Estimation is relative, not absolute  The purpose is only to help plan the sprints, nothing else
Scrum Board Backlog Conceptual Design Schematic Design Construction Docs Done User Story 1 User Story 2 User Story 3 User Story 4 Task 4 Task 2 Task 3 Task 1 Task 5 Task 4 Task 3 Task 2 Task 1 Task 4 Task 3 Task 2 Task 1 Task 2 Task 3 Task 1
Burndown Chart
User Stories - Why • Requirements are a communication problem. • If business side dominates, functionality and dates are mandated with little regard for reality. • If engineers dominate, technical jargon replaces the language customers can understand. • Many customers cannot articulate their needs until they see something. You built what I asked for, but it’s not what I need.
User Stories - What The 3 C’s • Card – stories are traditionally written on notecards, and these cards can be annotated with extra details • Conversation – details behind the story come out through conversations with the Product Owner • Confirmation – acceptance tests confirm the story is finished and working as intended
Anatomy of a User Story • “As a <role>, I want <feature> so that <benefit>.” • “In order to <receive benefit> as a <role>, I want <feature>.” • “As a <role>, I want <feature> so that <benefit>. I’ll know it’s done when <acceptance criteria>.” • “As a <role>, I want <feature>.”
“INVEST” in good User Stories • I – Independent (of all others, to the extent possible)* • N – Negotiable (not a specific contract for features) • V – Valuable (to the business, or to the end user) • E – Estimable (to a good approximation) • S – Small (enough to fit within an iteration)* • T – Testable (in principle, even if there isn't a test for it yet) * The more we break the stories down to make them smaller, the more difficult it becomes to keep them independent. It’s a tread-off we should be aware of, and balance independence with size.
…and “SMART” Tasks • S – Specific • M – Measurable • A – Achievable • R – Relevant • T – Time-boxed
How to create User Stories? • Start with Users • Create Personas with goals • Derive Epics from Persona Goals • Progressively decompose Epics into User Stories • Make the Stories ‘Ready’ (clear, feasible, testable) • Add Acceptance Criteria
Scrum Tools • Rally (now CAAgile Central) • IceScrum • Taiga • YouTrack • Hansoft • JIRA
Game Time☺ All talk and no play makes session a dull affair
Kanban
Kanban in a nutshell • Developed as a scheduling system in Toyota for lean manufacturing • A delivery flow system that limits the amount of work in progress (WiP) by using visual signals • Work is “pulled” into the system when other work is completed and capacity becomes available, rather than “pushed” into it when new work is demanded.
3 simple rules • Visualize Workflow • Limit WIP (Work in Progress) • Manage Flow
Why Kanban • Sometimes time-boxing doesn’t work • Easy integration with other processes • Does not mandate cross-functional team • Minimal entry barrier
Creating a Kanban board Backlog In Progress Done
Creating a Kanban board Backlog In Progress 4 Done
Creating a Kanban board Backlog Ready 2 In Progress 4 Done
Creating a Kanban board Backlog Ready 2 Conceptual Design 1 Schematic Design 2 Construction Docs 3 Done
Creating a Kanban board Backlog Ready 2 Conceptual Design 1 Schematic Design 2 Construction Docs 3 Done Doing Done Doing DoneDoing Done
Creating a Kanban board Backlog Ready 2 Conceptual Design 1 Schematic Design 2 Construction Docs 3 Done Doing Done Doing DoneDoing Done Swim lanes based on Priority/ Due date/ Nature of work
Cumulative Flow Diagram
Kanban Tools • LeanKit • YouTrack • Hansoft • Rally (now CAAgile Central) • JIRA
Scrumban
Scrumban in a nutshell • Can be used for transitioning teams from Scrum to Kanban • Has a Scrum-like board but with WIP limit on each column • Board is persistent but can be reset as needed • Team plans only when there’s need
Agile Resources • http://agilemanifesto.org (The Agile Manifesto) • https://scrumguides.org (Official Scrum Guide) • Scrum and XP from the Trenches (A good, practical guide on Scrum) • Essential Kanban Condensed (Kanban basics) • Kanban and Scrum – Making the Most of Both (Difference b/w Scrum and Kanban) • Is agile project management applicable to construction? (Research paper)
&A Q

More Related Content

Introduction to Agile - Scrum, Kanban, and everything in between

  • 1. Introduction to Agile Scrum, Kanban, and everything in between Pravin Singh
  • 3. The world before Agile Safeguard – Anti-Ballistic Missile Defense System • 1969 – 1975, 5407 person years • Cost: $25 Billion (not adjusted) • The project was delivered according to specifications
  • 4. The world before Agile Safeguard – Anti-Ballistic Missile Defense System • 1969 – 1975, 5407 person years • Cost: $25 Billion (not adjusted) • The project was delivered according to specifications Operational for 133 days, project terminated in 1978 By the time the 6 year anti-missile system project was completed, the new missiles were faster than the anti-missile missiles.
  • 5. Then came Agile • Iterative, Incremental, based on Inspect & Adapt • Focuses on fail-fast • Very Lightweight – focused on working software, not on processes • Requirements evolve over time • So does Design Humphrey’s Law: Users will never know what they want until they see it in production.
  • 6. The Iron Triangle - Waterfall Scope Schedule Cost Plan Driven
  • 7. The Iron Triangle - Agile Scope Schedule Cost Value Driven
  • 8. Delivery Verification Work Breakdown - Agile Requirements Design Implementation Feature1 Feature2 Feature3 Feature4 Feature5 Feature6 Feature7 Feature8
  • 9. Painting the Mona Lisa - Waterfall
  • 10. Painting the Mona Lisa - Agile
  • 11. Why Agile • Helps handle changing requirements and priorities • Lowers cost of change • Provides better visibility into project progress • Reduces risk • Maximizes Return on Investment (business value prioritization) • Delivers business value early and often
  • 12. The Agile Manifesto 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.
  • 13. Agile Values and Principles • Our highest priority is to satisfy the customer through early and continuous delivery. • Welcome changing requirements. Agile processes harness change for the customer's competitive advantage. • Business people and engineers 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 team is face-to-face conversation.
  • 14. Agile Values and Principles • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, engineers, and users should be able to maintain a constant pace indefinitely. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self- organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • 16. When Agile works best • Unclear/evolving requirements • Changing priorities • Customer availability • Collocated team • Flexible funding (like Time & Material contracts)
  • 17. When Agile does NOT work so well • Firm Fixed Price (all-or-nothing) contracts • Different vendors for different phases • Unavailability of customer • Stable, upfront requirements
  • 18. Game Time☺ All talk and no play makes session a dull affair
  • 19. Scrum
  • 20. Scrum in a nutshell
  • 21. Scrum Roles Product Owner • Voice of customer • Owner of the Product Backlog • Prioritizes the items to best achieve goals and missions • Optimizes the work of the development team
  • 22. Scrum Roles Development Team • Cross-functional • Self-organizing, self-managed • Has no sub-teams and no titles (other than team member) • Generally of size 3-9 members
  • 23. Scrum Roles Scrum Master • A servant-leader for the team • Removes impediments • Facilitates Scrum events • Helps Product Owner maintain the backlog • Coaches and guides
  • 24. Scrum Events • The Sprint • Sprint Planning • Daily Scrum (Standup) • Sprint Review (Demo) • Retrospective
  • 25. Scrum Artifacts Product Backlog • Ordered list of requirements • A living document (is never complete) • Per Product, not per Team • Owned by the Product Owner Sprint Backlog • Items selected for the Sprint • Only team can change it during Sprint
  • 26. Estimation& Velocity • Hours/ Days • T-shirt sizes • Story Points  Estimation is relative, not absolute  The purpose is only to help plan the sprints, nothing else
  • 27. Scrum Board Backlog Conceptual Design Schematic Design Construction Docs Done User Story 1 User Story 2 User Story 3 User Story 4 Task 4 Task 2 Task 3 Task 1 Task 5 Task 4 Task 3 Task 2 Task 1 Task 4 Task 3 Task 2 Task 1 Task 2 Task 3 Task 1
  • 29. User Stories - Why • Requirements are a communication problem. • If business side dominates, functionality and dates are mandated with little regard for reality. • If engineers dominate, technical jargon replaces the language customers can understand. • Many customers cannot articulate their needs until they see something. You built what I asked for, but it’s not what I need.
  • 30. User Stories - What The 3 C’s • Card – stories are traditionally written on notecards, and these cards can be annotated with extra details • Conversation – details behind the story come out through conversations with the Product Owner • Confirmation – acceptance tests confirm the story is finished and working as intended
  • 31. Anatomy of a User Story • “As a <role>, I want <feature> so that <benefit>.” • “In order to <receive benefit> as a <role>, I want <feature>.” • “As a <role>, I want <feature> so that <benefit>. I’ll know it’s done when <acceptance criteria>.” • “As a <role>, I want <feature>.”
  • 32. “INVEST” in good User Stories • I – Independent (of all others, to the extent possible)* • N – Negotiable (not a specific contract for features) • V – Valuable (to the business, or to the end user) • E – Estimable (to a good approximation) • S – Small (enough to fit within an iteration)* • T – Testable (in principle, even if there isn't a test for it yet) * The more we break the stories down to make them smaller, the more difficult it becomes to keep them independent. It’s a tread-off we should be aware of, and balance independence with size.
  • 33. …and “SMART” Tasks • S – Specific • M – Measurable • A – Achievable • R – Relevant • T – Time-boxed
  • 34. How to create User Stories? • Start with Users • Create Personas with goals • Derive Epics from Persona Goals • Progressively decompose Epics into User Stories • Make the Stories ‘Ready’ (clear, feasible, testable) • Add Acceptance Criteria
  • 35. Scrum Tools • Rally (now CAAgile Central) • IceScrum • Taiga • YouTrack • Hansoft • JIRA
  • 36. Game Time☺ All talk and no play makes session a dull affair
  • 38. Kanban in a nutshell • Developed as a scheduling system in Toyota for lean manufacturing • A delivery flow system that limits the amount of work in progress (WiP) by using visual signals • Work is “pulled” into the system when other work is completed and capacity becomes available, rather than “pushed” into it when new work is demanded.
  • 39. 3 simple rules • Visualize Workflow • Limit WIP (Work in Progress) • Manage Flow
  • 40. Why Kanban • Sometimes time-boxing doesn’t work • Easy integration with other processes • Does not mandate cross-functional team • Minimal entry barrier
  • 41. Creating a Kanban board Backlog In Progress Done
  • 42. Creating a Kanban board Backlog In Progress 4 Done
  • 43. Creating a Kanban board Backlog Ready 2 In Progress 4 Done
  • 44. Creating a Kanban board Backlog Ready 2 Conceptual Design 1 Schematic Design 2 Construction Docs 3 Done
  • 45. Creating a Kanban board Backlog Ready 2 Conceptual Design 1 Schematic Design 2 Construction Docs 3 Done Doing Done Doing DoneDoing Done
  • 46. Creating a Kanban board Backlog Ready 2 Conceptual Design 1 Schematic Design 2 Construction Docs 3 Done Doing Done Doing DoneDoing Done Swim lanes based on Priority/ Due date/ Nature of work
  • 48. Kanban Tools • LeanKit • YouTrack • Hansoft • Rally (now CAAgile Central) • JIRA
  • 50. Scrumban in a nutshell • Can be used for transitioning teams from Scrum to Kanban • Has a Scrum-like board but with WIP limit on each column • Board is persistent but can be reset as needed • Team plans only when there’s need
  • 51. Agile Resources • http://agilemanifesto.org (The Agile Manifesto) • https://scrumguides.org (Official Scrum Guide) • Scrum and XP from the Trenches (A good, practical guide on Scrum) • Essential Kanban Condensed (Kanban basics) • Kanban and Scrum – Making the Most of Both (Difference b/w Scrum and Kanban) • Is agile project management applicable to construction? (Research paper)
  • 52. &A Q