We’ve tried and its either painful or pointless…
High performing teams see the value of Retrospectives — the information they track, data, gives them critical insight into their agile process and more importantly, how to improve. Backed by data, retrospectives are more actionable than subjective and data automatically provides a great focus for conversation.
Every team has their own unique style and preferred techniques for facilitating Retrospectives. Its fine to use out-of-the-box models, or create one to match the way you work. If you’re new to the technique or simply looking for tips to re-invigorate your current practises, data and acceptance of failure are crucial! Read on…
1. Transparency rules. Research demonstrates that teams who share their performance data 24/7 or on a weekly basis are the most satisfied with their communication process. The easiest way to increase your sharing cadence is to create a live, dynamic display of burn-down, recurring impediments and time-to-unblock, high points and low points. It doesn’t have to be elaborate, flip charts on the wall are fine, just keep it real and current.
It demonstrates your professionalism. Everyone knows exactly where you are, what great work you’re doing and what challenges you dealing with. You can keep a simple version in a high-traffic area (ie canteen wall) to raise your credibility. It also keeps your goal front of mind, therefore maintains your focus. It will track the things you will forget, want to forget and should celebrate when you have your Retrospective. It will enrich your Retrospective, making sure it stays purposeful and doesn’t turn negative.
2. Start with the end (Goal) in mind. It’s easy to set vanity metrics and focus on the easy things that just don’t add value to your team. We see so much focus on the wrong things in Retrospectives that they really can be pointless so don’t fall into the trap of an hour of high-fives and post-its but no tangible outcome. The first exercise of your Retrospective is to each add post-it-notes to groups of what worked — what didn’t — what will we improve.
A simple example might be that we failed our Sprint because of functional defects when shown to Users at the Review.
Goal: Improve our UAT pass rate and deliver Sprint Goal
What worked — finishing one story before starting the next
What didn’t — poor acceptance criteria meant 15% rework (quantify it)
What to improve:
– specify acceptance criteria as your Definition of Ready
– improve Backlog refinement to include clarification with Users
– ensure you User test each story as you go
– find a Learning Asset and share it with your team
Now refer back to your business goal. How does your improvement point accelerate you towards that goal? In this case, you would reduce your rework, waste and improve your credibility with the business. And you genuinely improve the right things! OK, that’s a simple example but the point is you can’t have that discussion without meaningful data.
To quote Steven Covey “Be honest. Sometimes people find themselves achieving victories that are empty — successes that have come at the expense of things that were far more valuable to them. If your ladder is not leaning against the right wall, every step you take gets you to the wrong place faster”.
3. Celebrate Success but not Failure. Just as you choose one point to improve, choose one to celebrate. If you’ve had a successful Sprint then enjoy, celebrate something specific.
Don’t fall into the bland “beer & pizza” free for all or “hail the superstars” celebration that so many teams have come to expect. Look within your team and at your data. Have you found some hidden gem during backlog refinement? Have you overcome a major tech challenge? What have you learned this Sprint that will significantly change the way you move forward? Find a genuine reason to celebrate.
And if you’ve failed, don’t celebrate. There’s a frequently misunderstood saying “fail fast” which sounds like failure is absolutely fine, no problem. We see teams celebrate poor performance out of sheer habit, and learning nothing in the process. Again, data is your friend because you can pinpoint where, how why you failed. You may find that you failed the Sprint but learned something important or that you even decide to change direction in some way and that’s good. Emphasise teamwork and highlight shared credit, consequences as well as shared learning opportunities. Make sure failure isn’t about blame for sure but accept it. Denial of failure is failing to improve.
And, let’s be honest: even in the most progressive and understanding of workplaces admitting to failure is embarrassing. Don’t do it! Save the beer and pizza for another day when it really will be more meaningful.
コメント