Retrospectives are an invaluable tool for improving team dynamics, processes and productivity. The more frequently retrospectives are held, the more likely participants will provide honest feedback and be receptive to the ideas of others if they only happen after something really bad happens they’ll be associated with negativity, which isn’t the intent. These micro-retrospectives can be limited to just a topic or two, but addressing any event that went well (or didn’t) promptly and in a collaborative environment is a great way to learn from the mistakes or successes and build on those in the future. Retrospectives can be held more frequently, including for minor releases, each sprint or even at daily or weekly standups. How often should you hold retrospectives?Īny major release or project deserves a retrospective and should be held within a week of shipping before people forget what happened and move on to the next thing. While these topics might have come up in another venue, the process of running through the entire project in a retrospective gives everyone the opportunity to discuss them in a group setting dedicated to looking back at what transpired, with the explicit goal of continuous improvement. It is an opportunity for customer support to share how they were inundated with complaints about a clunky rollout or how the UX team delivered really clear wireframes that sped up the coding process. Participants should walk away from the retrospective with a better sense of how the project was experienced by everyone involved. Scheduling, resource allocation, documentation, communication, testing… they’re all viable topics for the discussion. To make sure no one feels too singled out or put on the defensive, retrospectives should explore every aspect of the project, from locking in the requirements to the execution of the marketing plan. The goal is not to lay blame and find fault in individuals, but rather to discuss what everyone could do better, more or differently next time around. While a retrospective may occasionally massive issues that must be addressed, they’re far more likely to shine a spotlight on incremental improvements for existing processes and habits. The goal is to understand how to replicate the positives in future projects by creating new best practices (or reinforcing existing ones) while identifying the root causes for the negatives so they can be prevented or mitigated going forward. What is the ideal outcome of a retrospective meeting?Įvery retrospective should at a minimum result in a list of “things that went well” and “things that could use improvement.” Those lists may not be particularly long and exhaustive, but each project probably has a few standouts in each column.īeyond calling these items out, the discussion should uncover why these things occurred. However, an impartial third-party of facilitator can also be used to ensure everyone is treated equally and given a fair share of floor time. These meetings are often led by product management as they’re the most cross-functional role in the organization and have a broader view of what happened during the project. The meeting should be considered a safe space for bringing up contentious issues and contrarian views for it to be as productive and insightful as possible. This can include marketing, sales, customer service, and operations representatives as well.Īlthough pointing out the flaws and problems encountered is important, participants are equally encouraged to bring up the positive aspects as well. A representative from each group should be present (if not, everyone involved), with each person given floor time to share their view of the experience. The meeting format is key to an effective retrospective since the value comes from the conversation and dialogue, not just a bunch of individual statements. An agile retrospective forces the entire team to pause and reflect on what transpired and discuss what worked and what didn’t during a particular project. In an agile environment, the focus is primarily on quickly getting releases out the door and worrying about what’s next, so there often isn’t a lot of discussion of what’s already in the rear view mirror. This concept has been preached by many in a variety of disciplines, and product development is no exception. Those who don’t learn from the past are doomed to repeat those mistakes in the future. Definition: A retrospective is a meeting held after a product ships to discuss what happened during the product development and release process, with the goal of improving things in the future based on those learnings and conversations.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |