The document outlines the principles and practices of agile methodologies, focusing on frameworks like Scrum and Kanban. It emphasizes the importance of collaboration, iterative development, and continuous improvement in software delivery. Key concepts include open teamwork, sustainable pace, and adaptive planning to enhance productivity and product quality.

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?

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

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

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

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

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!

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

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

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