Downloaded 19 times
Uploaded byDavid Hawks
Intro to agile for product managers
The document introduces agile principles specifically tailored for product managers, emphasizing the shift from traditional waterfall development to an empirical process. It outlines the roles and responsibilities of the product owner, including clarifying priorities, managing the product backlog, and facilitating stakeholder feedback. Key concepts include measuring progress through working software and adapting to evolving customer needs and project requirements.
More Related Content
Similar to Intro to agile for product managers
Intro to agile for product managers
- 1. INTRO TO AGILEFOR PRODUCT MANAGERS
- 3. Intro to Agilefor Product Managers After reading this, introduce yourself to a person seated next to you, tell this person why you are here and what you want to learn from this session. Write down your: Struggles with Current Process Agile Questions One item per post-it note Place on the Wall Sheets
- 5. David Hawks CEO ofAgile Velocity Agile Trainer and Coach Certified Scrum Coach (CSC) Certified Scrum Trainer (CST) Agile Austin Board Member (Education Chair) @austinagile austinagile.com (blog) Transforming Technology Organizations
- 6. Intro to Agilefor Product Managers Why Agile?
- 7.
- 8.
- 9. Three things wewish were true 9 1. 2. 3. The customer knows what he wants The developers know how to build it Nothing will change along the way
- 10. Three things wehave to live with 1. The customer discovers what he wants 2. The developers discover how to build it 10 3. Many things change along the way
- 11. Empirical Process ControlModel 11
- 12. Intro to Agilefor Product Managers Who can untie a Knot?
- 13.
- 14. Illusion of Waterfall 14 80%Done?? Release Requirements Waterfall Design Development QA
- 15. Intro to Agilefor Product Managers What type of Progress Visibility is Important?
- 16. Working software isthe primary measure of progress 16 Sprint 2 Sprint 3 Sprint 4 Requirements Requirements Requirements Requirements Design Design Design Design Development Development Development Development QA Agile Sprint 1 QA QA QA Potentially Releasable Product Increment
- 17.
- 18.
- 19. Intro to Agilefor Product Managers What is the Purpose of the Product Owner?
- 20. 20 Product Owner isin the Game The Product Owner is present and available to clarify priorities, answer product questions and give feedback on work-in-progress. Answering Questions Preparing Backlog Clarifying Priorities Facilitating Feedback from Stakeholders
- 21. Backlog Physics 21 The ProductOwner should be constantly grooming the Backlog • • • • Change items Add items Delete items Break big items into smaller ones • (deleting the big one) • Re-prioritize • Add details • De-prioritize items to make room for new items
- 22.
- 23. 23 Product Owner Responsibilities Forms asingle view of the prioritized requirements for the team Ensures features are defined with clarity Accepts or rejects work results Available to review daily work product to ensure on track Manages customer/ stakeholder expectations
Editor's Notes
- #2 Prep before Meeting Day 1: Print Backlog for story writing and cut out (Tab 1 titled Feature Requests of Agile Training.xlsx) Print Velocity charts for teams (Tab 2-5 titled Team 1-4 of Agile Training.xlsx) Measure perimeter of room with tape measurePrep before Meeting Day 2: Print Cards for Scrum Roles Skit and cut out (Tab 6 titled “Daily Scrum Roles Skit” of Agile Training.xlsx) Make balloon that meets spec without others seeing you. (~10 inches wide, ~2 inch eyes, ~1 inch gap between eyes, ~1.5 inch high nose, and ~4.5 inch wide mouth) Print Feedback FormsSetup Setup tables for teams Put all supplies on tables available to the team (except special supplies listed above)Supplies4x6 index cards for stories (1 stack per table)3x5 index cards for tasks (1 stack per table)Stickies (1 square pad per person)Chart board pads (1 per table)Sharpies (1 per person)Paper (1 ream per table)Scotch TapeMasking TapeButcher Block paper for task board (if a whiteboard area is not available)Chips for Chip Flip Game (20 per 10 people)Brochure Game (1 per table)Different color markersScissorsGlue stickConstruction paperMagazines (for clipping images)Ruler20-30 balloons per team25 ft tape measure
- #6 Couple questions?Who is working with software development teams?Who is employing Agile Methods?Who is using Scrum?Who is using Kanban?Who has heard of Kanban before?Give aways at the end. Let them choose which class they want a 50% discount on. Random person and who tweets
- #8 Winston W. Royce 1970 wrote originally about waterfall model and stated that he didn’t think it would work.But back then what did programming look like? Mainframes and punch cards, testing was very expensive so you needed to spend a lot of time up front.40 years later we know this model doesn’t work.
- #9 A defined process is an amount of tightly coupled steps where the output from one step is the input to the next step and where no observation or evaluation of the output is done to feedback to the process. A defined process when started will run to the end without any checkpoint. The output from a defined process should always be the same or with little variance given the same input to the process.For many years software development methodologies have been based on the defined process control model. But software development isn’t a process that generates the same output every time given a certain input.Ken Schwaber in Agile Software Development with Scrum
- #12 Provides and exercises control through frequent inspection and adaptationfor processes that are imperfectly definedand generate unpredictableandunrepeatable outputs.Scrum adopts an empirical approach accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team’s ability to deliver quickly and respond to emerging requirements.
- #15 In reality you are only 80% through the planYou have no verified working/ releasable softwareRisk Snowball Effect Too late to remove scopeIllusion that we are on trackIn reality you are only 80% through the plan or estimated effort.But at this stage in a waterfall project you have no verified working/ releaseable software.Haven’t verified that requirements were correct,Haven’t verified that design was sufficient,Haven’t verified that the code worksRisk Snowball Effect - Lot’s of risk has been building up until this point until you start verifying things during the QA cycleIt is too late to remove scope if you start uncovering that there is risk to delivering on time.In waterfall we give ourselves the illusion that we are on track when we really don’t know until the end. And then it is too late to do anything about it.
- #17 5 minIn Agile, we measure progress only when features are completely through verificationWe work on features incrementallyWe work on high value items firstThis allows us to adapt if our estimates were off and still adjust scopeWe minimize risk by always being at a known quality state after every Sprint
- #18 Allows us to track scope separate from Progress
- #19 15 min
- #23 5 min
- #24 5 minhttp://www.break.com/usercontent/2008/4/Office-Space-I-have-people-skills-488721