1 / 34

The Power of Retrospection

The Power of Retrospection. Linda Rising. Android programming Sang Shin. The Productive Programmer Neal Ford. Git Luca Milanesi o. Introduction to Scala Hubert Plocinicza k. Linda Rising www.lindarising.org linda@lindarising.org. Project Retrospectives.

naava
Download Presentation

The Power of Retrospection

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Power of Retrospection Linda Rising Android programming Sang Shin The Productive Programmer Neal Ford Git Luca Milanesio Introduction to Scala Hubert Plociniczak

  2. Linda Rising www.lindarising.org linda@lindarising.org Project Retrospectives

  3. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. agilemanifesto.org/principles.html

  4. Is that a postmortem?

  5. Project Retrospectives A retrospective is an opportunity for the participants to learn how to improve. The focus is on learning—not fault-finding. Norm Kerth

  6. Agile Retrospectives How to mine the experience of your software development team continually throughout the life of the project.

  7. Reflect and find a better way Here is Edward Bear, coming downstairs now, bump, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there is another way, if only he could stop bumping for a moment and think of it. A. A. Milne Winnie the Pooh

  8. Why a retrospective?To learn from the past We want to believe that learning from experience is automatic, but it requires profound skills. Experience provides data, not knowledge.

  9. Why a retrospective? To plan the future People want to improve themselves but usually they don’t know what to work on. When they get good feedback on specific goals, that releases the natural internal inclination to improve. James Fallows

  10. Why a retrospective?To reach closure Research shows that when organizations go through changes, people have feelings and thoughts but no place to express them in the normal course of business. Thus, their experience is carried forward as a heaviness that slows them down and keeps them from moving into the new setting with enthusiasm.

  11. Retrospective Examples Military: After Action Reviews, Navy Lessons Learned, Coast Guard Uniform Lessons Learned “Learning in the Thick of It,” M. Darling, Charles Parry, and Joseph Moore,, July-August 2005. Harvard Business Review Post-Fire Critiques chiefmontagna.com/Articles/post%20fire%20critique.htm The CEO & The Monk – corporate funeral

  12. What a retrospective isn’t No naming, no blaming. But praise is always welcome! Kerth’s Prime Directive: Regardless of what we discover, we must understand and truly believe that everyone did the best job he/she could, given what was known at the time, his/her skills and abilities, the resources available, and the situation at hand.

  13. Why take so much time? Memories are short and selective – Challenger experiment We tend to focus on recent events, especially if they are painful Technical people see technical problems, while many (or most) of the problems we face are people problems. External facilitation is required

  14. Appropriate times for a retrospective • At the end of project • While the project is still running • At milestones • Heartbeat • Custom – response to a “surprise”

  15. What are the driving questions? • What worked well that we don’t want to forget? • What should we do differently? • What did we learn? • What still puzzles us?

  16. Agile vs. End of Project On an agile project, each iteration should involve a few small experiments The retrospective questions should focus on the experiments, e.g. “What worked well about moving the time of our stand-up?” Agile retrospectives are about getting ready for the next iteration, not about solving all the problems the team has. You may not be able to solve a given problem, but you can always set up a small experiment.

  17. Who should attend? • Represent many viewpoints: • Development • Marketing • Customer Support • QA • Managers • May split into specialist groups e.g. Testers, Developers, to tackle special topics

  18. What happensDuring the meeting • Readying • Look at the past • Prepare for the future

  19. Ground Rules Examples: Try not to interrupt (use a talking stick) Speak from your own perspective and not speak for anyone else No jokes at the expense of anyone in the room

  20. Create Safety Create an atmosphere in which team members feel comfortable talking openly and honestly • Everything is optional • Secret ballot • 4 = “No problem” • 1 = “No way” • Establish ground rules

  21. Example Exercises • Readying • Look at the past • Prepare for the future • Artifacts Contest • Offer Appreciations • Time Line – agile teams do this in “real-time” • Mine for Gold

  22. What happensDuring the meeting • Readying • Look at the past • Prepare for the future Time Line Exercise

  23. What happensDuring the meeting • Readying • Look at the past • Prepare for the future Time Line Exercise

  24. What happensDuring the meeting • Readying • Look at the past • Prepare for the future • What worked well? • What to do differently? • What did we learn? • What still puzzles us?

  25. What happensDuring the meeting • Readying • Look at the past • Prepare for the future • Determine actions to take for the next iteration or release or project • Identify the next “experiment” • For agile projects, each iteration should identify a few small changes and ask “the driving questions” about those changes at the next retrospective

  26. How is knowledge shared? • Web postings. • Team meetings, staff meetings, tech forums. • Training courses. • Interaction during checkups and retrospectives. • Process feedback and knowledge sharing operates continuously. • Minstrels and story-tellers!

  27. How to “sell” retrospectives The purpose of a retrospective is learning • To avoid recurring mistakes • To identify and share successful practices • To prepare for the next iteration and future projects Everyone says they want to learn, but few take the time to do so. Fearless Change: patterns for introducing new ideas, Mary Lynn Manns & Linda Rising, Addison-Wesley, 2005.

  28. Facilitation resources International Association of Facilitators - certification program http://www.iaf-world.org/ ASTD - American Society for Training and Development - local chapters http://www.astd.org/index_NS6.html ISPI - International Society for Performance Improvement - certification, local chapters http://www.ispi.org/ NASAGA - North American Simulation and Gaming Association http://www.nasaga.org/ Workshops by Thiagi - Freebies http://thiagi.com/ Roger Schwartz, The Skilled Facilitator Sam Kaner et al, Facilitators Guide to Participatory Decision Making Ingrid Bens, Facilitate with Ease!  Josey-Bass Inc., 2000. R. Brian Stanfield, ed., The Art of Focused Conversation. ICA Canada,1977. R. Brian Stanfield, ed., The Workshop Book. ICA Canada, 2002. Training and development Yahoo group http://groups.yahoo.com/group/trdev/ Jean Tabaka, Collaboration Explained, Addison-Wesley, 2006

  29. Next Steps • Buy and read Norm Kerth’s book: Project Retrospectives, Dorset House, 2001 • Buy and read Esther Derby and Diana Larsen's book: Agile Retrospectives, The Pragmatic Bookshelf, 2006 • Check out Linda’s web site – click on Articles, then Retrospectives • Sign up for the Yahoo group: retrospectives

  30. Retrospectivesa closing thoughtfrom Norm Kerth (and Edward Bear) … we bump our heads in project after project, day after day. If we would only take a moment to stop and think of alternative ways to proceed, I’m sure we could find better ways to do our work.Norm Kerth

  31. BOF: Future of Java EE Alexis Moussine-Pouchkine BOF: Web framework shootout Błażej Bucko, Tomasz Dziurko, Wojciech Erbetowski, Łukasz Kuczera, Paweł Szulc BOF: Hack your company Jakub Nabrdalik BOF: Those broken, broken class loaders JevgeniKabanov

More Related