Agile Explained by LeanDog

  • 3,252 views
Uploaded on

We use this slide deck to explain the Agile practices that we teach. This is what we call our "Agile Buffet", you don't have to adopt all of these practices but you should understand them so that you …

We use this slide deck to explain the Agile practices that we teach. This is what we call our "Agile Buffet", you don't have to adopt all of these practices but you should understand them so that you can use them as necessary. We are always modifying this presentation, so if you want the most current one, contact us.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,252
On Slideshare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
137
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Words are tremendously slippery things - I looked for the original cartoon that inspired this but couldn ’t find it - but hopefully the point is clear, people are notoriously good at agreeing despite the ambiguity of language and traditional requirements documentation
  • End result not the same as any start point

Transcript

  • 1. Agile Explained Jon Stahl
  • 2. Agenda
    • Introductions
    • Your Expectations
    • Video
    • Key Concepts
    • Key Processes
    • Lunch
    • Kanban Explained
    • Process Check
      • Scrum vs. Kanban
    • Product Owner Practices
    • Team Facilitator Practices
    • Quality Assurance Practices
    • Engineering Practices
    • Feedback Form
    • Take a Book
  • 3. [email_address] Co-Founded 2.5 Years Ago Grew up in Pittsburgh, in Cleveland last 18 years BS in CIS + Econ Minor @jonRstahl
  • 4. “ The Kearsarge” A Steamship built in 1892 Our office/boat
  • 5. “ The Deep Dive” - 1999 How does the process of designing a better product work? What does a process AND a culture look like?
  • 6.
  • 7.
    • Process + Culture := Sustainability
    “ Build a culture and a process, that's what companies really want”
  • 8. What is Agile?
    • Term “Agile Methods” adopted in 2001
    • Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming
    • Sympathetic to the need for an alternative to documentation driven, heavyweight software development processes
    • Experts gather at a ski resort in Utah
      • Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn
      • Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith
      • Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin,
      • Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
    • Values and Principles !!!!!
  • 9. Agile Manifesto
  • 10. Agile Principles
    • Deliver software in short increments
    • Expect and encourage change
    • Constant collaboration with customer
    • Continuous attention to technical excellence
    • Simplicity
    • Self organizing teams
  • 11. Leandog Studies…
    • Scrum
    • eXtreme Programming
    • Lean
    • Group Dynamics
  • 12. eXtreme Programming (XP) Values
    • Simplicity
    • Communication
    • Courage
    • Feedback
    • Respect
  • 13. 5. Alistair Cockburn, http://alistair.cockburn.us/Oath+of+Non-Allegiance
  • 14.
  • 15. CONCEPTS Concepts Whole Team Open Workspace T-Shaped People Sustainable Pace Big Visible Charts Frequent Releases Story Card Wall Roadblocks Process Scrum Framework Product Backlog Story Card Writing Estimation/Sizing Release Planning Sprint/Iterations Sprint/Iteration Planning Daily Scrum/Stand Up Show & Tell Retrospectives Velocity Customer Collaboration Kanban
  • 16. Whole Team
    • All skills necessary for project to succeed should be on the team
    • Team composition should be dynamic
    • The team must be self empowered
      • The right people in the right seats
      • They are led, not managed
      • They communicate and collaborate continuously
      • They are accountable for the results
  • 17. Whole Team Worksheet
    • Use this template to begin to reorganize your group into an Agile Team
  • 18. Open Workspace
    • Facilitates constant communication
    • Builds the sense of team
    • Should be set up for pairing
    • Parents Ear: Silence or kicking/screaming = bad
    • Lose the sensory deprivation chambers
    Note: This is the hardest practice to adopt, but most rewarding when done.
  • 19. Open Space
  • 20. T-Shaped People
    • T-Shaped / Cross Training / Avoid Silos
      • Pairing
      • Queue Limits (Kanban)
      • Sign up for work
  • 21. Sustainable Pace
    • Ensures the team has time to plan, think, rest, and deliver effectively
      • Hard 40 hours, maintainable pace
      • Throughput consistency
      • Avoid mistakes
      • Card process and limited WIP support this
      • Sustainable fun is evident in room
  • 22. Big Visible Charts
    • A display posted in a place where people can see it as they work or walk by.
    • It shows readers information they care about without having to ask anyone a question.
    • This means more communication with fewer interruptions.
    • Large & easily visible to the casual, interested observer
    • Understood at a glance
    • Changes periodically, so that it is worth visiting
    • Is easily kept up to date
  • 23. Clear communication is the foundation “ I’m glad we all agree.”
  • 24. Get those mental models out on the table “ Ah...”
  • 25. An explicit model allows convergence through iteration “ Ah!”
  • 26. A genuinely shared understanding “ I’m glad we’re all agreed then.”
  • 27. Big Visible Charts
    • Information radiators, transparency
    • Should include:
      • Story card wall
      • Road block board
      • Burn Down Charts
      • QA status
      • Production stats
      • Retrospective items
    • Should also include anything necessary to keep team and customer informed on status and progress
  • 28. Frequent Releases
      • Done means Automated Testing Completed
      • Every iteration close should be very close to releasable
      • May need to do some extra integration & stress testing
      • Customer decides when to “pull” release
      • Large Releases = High Risk
      • Release is most important form of feedback & Business Value Incrementally
      • Value is realized sooner
  • 29. Story Card Wall
        • Work in progress, Card is “currency”, must be physical
        • Must be readable to outside
  • 30. Roadblocks
        • Displayed on the wall in each team area
        • Are prioritized
        • Reviewed at end of each iteration/sprint
        • When in progress there should be a owner of the card
  • 31. PROCESS Concepts Whole Team Open Workspace T-Shaped People Sustainable Pace Big Visible Charts Frequent Releases Story Card Wall Roadblocks Process Scrum Framework Product Backlog Story Card Writing Estimation/Sizing Release Planning Sprint/Iterations Sprint/Iteration Planning Daily Scrum/Stand Up Show & Tell Retrospectives Velocity Customer Collaboration Kanban
  • 32. Scrum Framework Daily Stand Ups Sprints
  • 33. Product Backlog
    • Should be Visible
    • Must be prioritized
    • Backlog is organized by business value
    • Backlog is regularly reviewed and maintained
    • Does not include vacations, meetings or other items not pertaining to the product
    • Just enough product backlog to create product without unnecessary features
    • Story Cards are the backlog
  • 34. Story Card Writing
    • They are the unit of deliverable for an Agile team
    • They are a sentence or two describing a set of new functionality
    • Must be testable and should include acceptance criteria
    • The details are elaborated via conversation between the customer, developer and QA
    • Start of a conversation
  • 35. Story Card Writing
    • Independent
    • Negotiable
    • Valuable
    • Estimable
    • Small
    • Testable
  • 36. Estimation & Sizing
      • Estimated as T-Shirt Sizes:
        • Extra Small < 1 Day 1 Unit
        • Small 1 – 2 days 2 Units
        • Medium 3 – 4 days 4 Units
        • Large 5 – 6 days 8 Units
        • Extra Large 7 – 10 days 16 Units (Never!)
    • Coding Estimate Only
    • Assumes relative complexity correlates to analysis & QA effort
    • Sizing ! – Therefore we talk in units!
    • Ideal day estimates, we will measure what reality is
    • Each size is double the size of the previous
  • 37. Poker Planning
    • All Developers take a set of cards
    • Take the team average
    • Do it fast, do it often
    • “ Cheap” to do
    • Things always change (people, systems, customer vision)…
    • Therefore estimates should too
    • Adaptive, not predictive!
  • 38. Release Planning
    • Large Sheets of paper
    • Each sheet represents one iteration
    • Put “guessed” velocity in units at top
    • Begin to lay out cards in feature importance order
    • Cannot go over unit limit
    • When done, tape cards down
    • Enter into Story Card management system
    • Produce burn down charts
    • The team should review plan and ask the following questions…
      • Enough work for all pairs?
      • Any pairs stepping on others?
      • We should play highest risk cards first, are we?
      • Do we have the most valuable features coming out first?
      • Any dependencies we are missing?
  • 39. Release Planning
  • 40. Sprint / Iterations Planning
    • 1 to 2 hour Iteration Planning Meeting
    • kicks off each new iteration
      • Close the previous
        • Conduct show & tell
        • Review current velocity
        • Hold retrospective
      • Open the new
        • Available work hours and set velocity target
        • Review business intent for new cards
        • Re-estimate cards if necessary
        • Determine what fits into this iteration
        • Sign up for cards
  • 41. Daily Scrum / Stand Up
    • Team communicates status of its work on a daily basis
    • Team members report:
      • What they did yesterday
      • What they are going to do today
      • Any concerns or road blocks they are facing
    • Each update is very brief
    • 15 minutes for whole team
  • 42. Daily Scrum / Stand Up
    • They reduce the need for full blown team meetings
    • They encourage accountability because team members are aware of all work going on
    • They allow for mid-course corrections
    • The encourage the team to solve problems on their own
    • Managers hear about road blocks early
  • 43. Show & Tell
    • Mini UAT of software for Customer
    • Developers usually drive
    • Team gets to hear customer feedback
    • Team “see’s the whole” of the software, stays in synch
    • Customer can prioritize changes immediately
    • Accountability to customer and satisfaction
  • 44. Retrospectives
    • Designed to help a team find ways to improve what they do
    • Should be held at each IPM
    • What worked? What didn’t work?
    • Team votes if items discussed during the retrospective should become cards to be played in the coming iteration
    • Courage, Communication, Respect
  • 45. Retrospectives
    • Help develop continuous improvement cycle
    • Should be held every iteration, in IPM is ideal, have as frequent as necessary
    • Make action items visible
    • Ensure courage, communication and respect are adhered to
    • Basic Format
      • What didn’t work or was confusing
      • What worked
      • Determine if any changes should be made in next iteration, create a card for this and get business buy in
  • 46. Velocity
    • Track number of units completed in an iteration
    • Yesterday's weather
      • Best estimate of what you can complete in the current iteration is what you completed in previous iteration
    • Plan using trailing average, 3 two week iterations
    • Estimate time based on velocity
    • Don ’ t compare teams
  • 47. Customer Collaboration
    • In Agile the customer drives everything
      • Requirements
      • Prioritization
      • Review of work
      • completed
    • Not always possible to have customer on site
      • Should have customer surrogate
  • 48. Kanban
    • Kan means &quot;visual,&quot; and ban, means &quot;card&quot; or &quot;board”
    • Uses cards to signal the need for an item.
    • 3 Rules: Visible, Strict Queue Limits, Pull Value
    • Measure time for each card size to flow through all steps
  • 49. Manage to Learn, Servant Leader, Team Facilitator, Intellectual Honesty, Passion for Learning
  • 50.
  • 51. A3
    • Regular Management Retrospectives
    • Communication of Strategy, ensures everyone understands the strategy
      • Use a A3 Paper
      • What objectives do you have in place?
      • Do you have countermeasures in place?
      • Did you go to the gemba?
      • Are understood and visible to whole team
      • 5 why method is applied
    • Encourage reading, buy and distribute reading material to team
    • Have lunch and learns
    • Attend your group’s show and tells periodically
  • 52.  
  • 53. Exploratory Testing
    • Manual tests that occur after story is developed
    • Used to catch the edge cases that aren’t caught in automation
    • Is part of the quality strategy for a team or a project
    • Involves the tester before the story card is implemented
    • Is context driven
  • 54. Automated Regression Testing
    • Agile teams deliver working software at the end of each iteration
    • QA team must perform full regression test each iteration as well as testing new functionality
    • Usually not possible without Automation
    • QA should:
      • Write manual test plan during story card elaboration
      • Execute manual test plan when story is ready
      • Once manual test passes automated test should be created and added to test suite
  • 55. Testing Quadrants
  • 56.  
  • 57. Collective Code Ownership
    • Any developer can change any piece of code at any time
    • Necessary to support continuous integration
    • Helps to eliminate “specialization” within systems
  • 58. Continuous Integration
    • Integration is a risky time for any project
    • Agile teams mitigate this risk by doing integration all of the time
    • Should happen at each developer check in (several times per day)
    • Software is built and all automated unit tests are run against the build
    • Dependencies are resolved and full integration takes place
  • 59. Simple & Evolutionary Design
    • The system is not designed up front – instead the system is designed at all times to support current application needs
    • Emphasis is placed on simple architectures and designs that provide adaptability to change
    • Simple designs also allow teams to have increased velocity as they are spending a greater percentage of their time providing customer value
  • 60. Paired Programming
    • Build quality in with constant collaboration and code review
    • Increase productivity due to two minds solving a problem
    • Knowledge moves across team more quickly
    • Ensure best practices are followed
  • 61. Test Driven Development
    • Developers write a test prior to writing application code
    • Tests ARE documentation, never stale, mirror logic
    • Places more emphasis on testing and quality during development
    • Reduces the number of defects that make it to QA
    • Simplifies design of application due to small incremental coding steps
    • Tests allow for fearless refactoring of system – it’s a instant feedback loop!
  • 62.  
  • 63. C#/.NET Developer Tools Start Write a Failing Test Write code to make it pass Stop Continuous Integration Test Driven Development Refactoring       Can’t think of any more tests Team City ReSharper Refactor 
  • 64. Technical Debt
      • Every system has debt
      • Don’t hide it, make it visible
      • Don’t pay debt – go bankrupt
      • All debt should be justified as business value (VSAM)
        • V elocity/Cycle Time
        • S calability
        • A vailability
        • M aintainability
      • Anything that makes code hard to change
        • Sloppy / Un-testable code
        • Dependencies (high cohesion & low coupling are essential for testable code)
  • 65. Spikes
      • Football = quick, stop clock, assess situation
      • Mitigate Risk
        • never done it, don’t know
        • just too large
      • Estimate the spike like anything else
      • Discovery
  • 66.  
  • 67. Low Fidelity Prototyping
    • more likely to give constructive feedback about the important aspects of the UX than if they were presented with a high-fidelity prototype or near complete version of the software
    • Light weight, no tools, fast
    • Build the software and let them touch it
    • Adapt
  • 68.  
  • 69.  
  • 70.  
  • 71. Acceptance Tests
      • Defines test BA would need to complete in order to sign off on the card
    • Two formats to choose from
      • Simple
    • Story: Adjust search radius
    • As a customer
    • I need to adjust the search radius
    • So I can increase or decrease the number of search results
    • Acceptance Criteria
      • Restrict customer to selecting 10,20,30, and 40 miles
      • If no customers in that radius, show message stating no agents found
      • If more than 15 agents, show all agents in radius
    • See mockup #2
  • 72. Acceptance Testing “Given When Then” Pattern
      • Use if you plan to use behaviour driven development tools such as Cucumber, JBehave, etc.
  • 73. Additional Story Card Artifacts
    • Should include Acceptance Tests
    • Might include
      • Screenshot
      • Formulas with Inputs and Outputs
      • Workflow rules
    Confidential. Copyright 2009 LeanDog, Inc. All rights reserved. Do not copy or distribute without permission.
  • 74. Value Stream Mapping
    • Flow of activities that starts with a customer in need and ends when the need is satisfied
    • Problem  ------ Value Stream -----  Solution
    Source: Michael Nygard http://www.michaelnygard.com/blog/2008/02/ Great read on value stream of Waterfall vs. Agile
  • 75. Personas
    • You don't &quot;make up&quot; personas, but instead discover them as a byproduct of your requirements investigation
    • Write specific personas: you will have a much greater degree of success designing for a single person
    • The &quot;generic user&quot; will bend and stretch to meet the moment, but your true goal should be to develop software which bends and stretches. 
    • Your personas should &quot;wiggle&quot; under the pressure of development
    • You want to know what the persona's goals are so that you can see what your system needs to do, and not dot
    • Sometimes you want to identify negative personas, people that you are not designing for. A primary persona is someone who must be satisfied but who cannot be satisfied by a user interface that is designed for another persona.
    •   If you identify more than three primary personas your scope is likely too large.
    • You want a finite number of personas, your goal is to narrow down the people that you are designing the system for. 
    Alan Cooper, The Inmates are Running the Asylum
  • 76. Personas
  • 77. Story Mapping
    • Early stage of progressive elaboration
    • Team uses post-it notes to depict the features and their flow in the system
  • 78. How well does it work?
    • The benefits most widely cited by the participants:
    • 93% Enhanced ability to manage changing priorities
    • 83% Improved project visibility
    • 74% Increased productivity
    • 74% Improved team morale
    Survey of 2319 companies taken in 2008
  • 79. “ The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.” - William Arthur Ward Fire Away! ;) Please fill out your feedback form so we can adapt and improve! Open Discussion & Acceptance Criteria Review
  • 80. Engagement with LeanDog
    • Software Delivery
    • Jump Start Programs
    • Trainers
    • Coaches
    • Practitioners