Module 09 demos and retrospectives gla
•Download as PPT, PDF•
0 likes•112 views
Agile Training
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Module 09 demos and retrospectives gla
Similar to Module 09 demos and retrospectives gla (20)
More from Sriram Angajala
More from Sriram Angajala (20)
Recently uploaded
Recently uploaded (20)
Module 09 demos and retrospectives gla
- 1. Agile Training ©2010 David Consulting Group 09 Demonstrations and Retrospectives 2013 The David Consulting Group Tom Cagley, CFPS, CSM VP of Consulting
- 2. ©2010 David Consulting Group The Scrum Process 0 50 100 150 200 250 300 350 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 Days Burn-up Chart Example Done 24 Hours 1-2 Weeks Daily Standup Iteration Backlog Product Backlog Continuous Reporting Demo Iteration Planning Potentially Shippable Retrospective
- 3. ©2010 David Consulting Group Sample Two Week Iteration Calendar Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Demo (1 hour)Demo (1 hour) Retrospective (1 hour) Retrospective (1 hour) Iteration Planning (2-4 Hours) Iteration Planning (2-4 Hours) Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Iteration1 Pre-Planning Meeting (1 hour) Pre-Planning Meeting (1 hour) Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Demo (1 hour)Demo (1 hour) Retrospective (1 hour) Retrospective (1 hour) Iteration Planning (2-4 Hours) Iteration Planning (2-4 Hours) Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Standup MeetingStandup Meeting Iteration2 Pre-Planning Meeting (1 hour) Pre-Planning Meeting (1 hour)
- 4. ©2010 David Consulting Group The Hurdle: Done • Definition of Done is a simple list of activities that add verifiable/demonstrable value to the product. • Focused on value-added steps to allow the team to focus on what must be completed in order to build software while eliminating wasteful activities. • Agreed in advance of the iteration. Source: http://www.scrumalliance.org/articles/105-what-is-definition-of-done-dod Definition of Done •writing code •commenting code •unit testing •integration testing •creating release notes •creating design documents •user testing •training completed
- 5. ©2010 David Consulting Group Planning the Iteration Demo / Review Meeting • Scheduled by the Scrum Master for the last day of the iteration • Target 1 hour to complete • Includes all members of the core team, and external stakeholders such as IT Leadership, clients, and business users
- 6. ©2010 David Consulting Group Running the Iteration Demo #1 – Setup the Demonstration – Make introductions, if necessary. – Review the business goals or theme of the iteration (if appropriate) – Identify issues or challenges that impacted the iteration goals. – Explain what the demo will show and what won't be working or is intentionally 'mocked' or stubbed out. #2 – Run the Demonstration – Review the specific user story that will be demonstrated – Demonstrate the system or solution, ideally with the Product Owner talking and someone managing the keyboard/mouse. – Capture any defects or issues and update backlog #3 – Ask for Feedback – When the demo is over, ask for feedback and also ask if the sponsors and stakeholders think things are on track (solicit feedback when the experience is fresh in their minds).
- 7. ©2010 David Consulting Group Avoid If At All Possible • Some things to avoid when showing a demo include: – software code – graphs or “stoplight” success indicators of unit tests – excessive emphasis on PowerPoint slides or screenshots of what the system should look like – Product Owner surprises
- 8. ©2010 David Consulting Group Possible Outcomes Of A Demo Applause!
- 9. ©2010 David Consulting Group Sprint Retrospective Meeting • Scheduled by the Scrum Master and held directly after the demo, and before Iteration planning • Target 1 hour to complete • Purpose is for Scrum team to discuss – What went well – What did not go well – What can be improved in subsequent sprints
- 10. ©2010 David Consulting Group How To: Retrospectives Overview • Retrospectives can be applied for Iterations, Releases and Surprise • Process – Norm Kerth's Prime Directive – Brainstorming (30 minutes ish) – Affinity Diagramming / Mute Mapping (10 minutes ish) – Retrospective objective (20 minutes ish)
- 11. ©2010 David Consulting Group How To: Norm Kerth’s Prime Directive Regardless of what we discover today, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. • Ask each attendee in turn if he agrees to the Prime Directive • Get a verbal "yes“ (IMPORTANT TO GET A VERBAL YES) • If not, I ask if he can set aside his skepticism just for this one meeting. If an attendee still won't agree, don't conduct the retrospective.
- 12. ©2010 David Consulting Group How To: Brainstorming • Hand out index cards and pencils, then write the following headings on the whiteboard: – Enjoyable – Frustrating – Puzzling – Same – More – Less • Ask the group to reflect on the events of the iteration and brainstorm ideas that fall into these categories. Write each idea on a separate index card. • Note ask each person to call out the idea as they write it.
- 13. ©2010 David Consulting Group How To: Affinity Diagramming / Mute Grouping • Ask the whole group to go to the board and group the ideas – Put related cards together – Put unrelated cards far apart – No talking • Once complete the facilitator will circle groups and discuss the name of the group • When named vote on which categories to improve during the next iteration. • Hand out little stickers to represent votes. Give each person five votes. • Participants can put all their votes on one category if they wish, or spread their votes.
- 14. ©2010 David Consulting Group How To: Retrospective Objective / Fix One Thing • After the voting ends, one category should be the clear winner. If not, don't spend too much time on it; flip a coin or something. • Discard the cards from the other categories. • Frustrated that your favorite category lost? Wait a month or two. If it's important, it will win eventually. • Come up with options for improving the ONE category. – Brainstorm some ideas. Half a dozen should suffice. – Don't be too detailed when coming up with ideas for improvement. A general direction is good enough. • When you have several ideas, ask the group which one they think is best. If there isn't a clear consensus, vote. • This final vote is your retrospective objective. Pick just one! • To encourage follow-through, make the retrospective objective part of the iteration.
- 15. ©2010 David Consulting Group Questions . . . Tom Cagley VP of Consulting The David Consulting Group t.cagley@davidconsultinggroup.com (440) 668-5717
Editor's Notes
- One hour is a guideline based on team size and the level of interaction with the participants. If significant levels of discussion are anticipated the duration may need to exceed 1 one.
- For the demo, use an actual business scenario and make it as realistic as possible
- Target time frame is used to ensure focus.
- Step 4: Retrospective Objective After the voting ends, one category should be the clear winner. If not, don't spend too much time on it; flip a coin or something. Discard the cards from the other categories. If someone wants to take a card to work on individually, that's fine, but not necessary. Remember, you'll do another retrospective next week. Important issues will recur. Frustrated that your favorite category lost? Wait a month or two. If it's important, it will win eventually. AllyRoot-Cause AnalysisNow that the team has picked a category to focus on, it's time to come up with options for improving it. This is a good time to apply your root-cause analysis skills. Read the cards in the category again, then brainstorm some ideas. Half a dozen should suffice. Don't be too detailed when coming up with ideas for improvement. A general direction is good enough. For example, if "pairing" is the issue, then "switching pairs more often" could be one suggestion, "ping-pong pairing" could be another, and "switching at specific times" could be a third. When you have several ideas, ask the group which one they think is best. If there isn't a clear consensus, vote. This final vote is your retrospective objective. Pick just one—it will help you focus. The retrospective objective is the goal that the whole team will work towards during the next iteration. Figure out how to keep track of the objective and who should work out the details. After the Retrospective The retrospective serves two purposes: sharing ideas gives the team a chance to grow closer, and coming up with a specific solution gives the team a chance to improve. The thing I dislike about iteration retrospectives is that they often don't lead to specific changes. It's easy to leave the retrospective and think, "Well, that's done until next week." If you're like me, the ensuing lack of action can be a little frustrating. To avoid this frustration, make sure someone is responsible for following through on the retrospective objective. It's not that person's job to push or own the objective—that's for the whole team—but it is his job to remind people when appropriate. To encourage follow-through, make the retrospective objective part of the iteration. For general behavior changes, such as "switch pairs more often," consider adding a big visible chart to your informative workspace. For specific actions, such as "improve database abstraction layer," create task cards and put them in your iteration plan.
- Think of events that were enjoyable, frustrating, and puzzling, and consider what you'd like to see increase, decrease, and remain the same.
- If someone wants to take a card to work on individually, that's fine, but not necessary. Remember, you'll do another retrospective next week. Important issues will recur. one—it will help you focus. The retrospective objective is the goal that the whole team will work towards during the next iteration. Figure out how to keep track of the objective and who should work out the details. After the Retrospective The retrospective serves two purposes: sharing ideas gives the team a chance to grow closer, and coming up with a specific solution gives the team a chance to improve. The thing I dislike about iteration retrospectives is that they often don't lead to specific changes. It's easy to leave the retrospective and think, "Well, that's done until next week." If you're like me, the ensuing lack of action can be a little frustrating. To avoid this frustration, make sure someone is responsible for following through on the retrospective objective. It's not that person's job to push or own the objective—that's for the whole team—but it is his job to remind people when appropriate. To encourage follow-through, make the retrospective objective part of the iteration. For general behavior changes, such as "switch pairs more often," consider adding a big visible chart to your informative workspace. For specific actions, such as "improve database abstraction layer," create task cards and put them in your iteration plan.