Do high-performing teams always need retrospectives?

by Sumeet Moghe

A few months back Patrick Kua wrote a blog conjecturing if the lack of retrospectives is really a smell. Pat mentioned how he was very lucky that the team had some really strong people who got things done and kept the project 'continuously improving'. To quote Patrick, “It’s amazing what a bunch of energized, passionate and people with the “solve the right problem once” attitude can achieve."

Reminiscing this post from Pat, I had a few thoughts. Given us agree that:
• retrospectives are a 'best practice';
• and that they are a tool for improvement;

Is it fair for us to say (at least theoretically) that we can take this 'best practice' to an extreme level just as rationale behind extreme programming may suggest?
• Second, Agile methods (at least theoretically) assume a team composed of the 'best people' who are 'generalizing specialists' or 'versatilists'.
• The key to having a really strong team could then be mechanisms that not only encourage strong communication, but also those that allow teams to recognize problems, find solutions. That then will fuel continuous improvement, perhaps making retrospectives purely an optional ritual.

What could these mechanisms be?
• My passion for retrospectives set aside, I realize that the practice is definitely more than a decade old in the mainstream. Things have changed significantly since then.
• More teams understand the value of solving problems 'just in time';
• Command and control leadership may have not disappeared from the horizon, but leaders are slowly discovering their roles in empowering their teams to take more control of situations and problems.
• Technology is changing fast and our ability to use tools to make problems visible solve them is fast increasing.
• Here are a few ideas I had to increase communication and to recognize and solve problems on a team. These ideas don't necessarily negate the requirement of a retrospective, but they can perhaps take us one step further to being high performing teams.

A low tech method - daily 'hot topics'

A few months back, we were a team of 7 people with Ritin Tandon at the helm as the team lead. Ritin devised a method for us to recognize issues and solve them on an ongoing basis. In the team area, Ritin put up a flip chart called "Hot Topics". Every time anyone in the team had something to discuss or a non-urgent problem to solve, they'd put up a sticky on the flipchart. At the end of the day, one of us (often Ritin) would facilitate a quick discussion around our hot topics and we'd volunteer to solve the problems then and there. If we expected that a problem would take time to solve, then one or more of us would sign up to work on it and we kept reporting back progress to the team. It has been a fantastic practice and for the investment of a few minutes each day, we got a huge sense of fulfillment by taking blockers out of our way. What we were doing was a bit of a mini-retrospective each day and that helped us be a continuously improving team.

A hi-tech method - use Web 2.0 tools to surface and resolve problems.

There are quite a few tools these days that can help create high quality communication in teams. Two tools that I think can be really useful to surface and resolve problems in a team are Google Wave and Google Moderator. And of course there’s the indigenous www.ideaboardz.com.

Google Wave
Google Wave follows the paradigm of blips. It could be quite easy to create retrospective playground on Google Wave where you create brainstorming blips (Keep Doing, Stop Doing, etc) on the wave and people can add their thoughts and following discussion under those blips. In fact I think this could be even better than a ritual retrospective where we often don't discuss issues because of a lack of time. Using this method, people can actually choose to comment on every issue they feel passionately about instead of restraining themselves only because others don't see the value in their thoughts yet!

Google Moderator
Google Moderator is a great social application to crowd source ideas. You could potentially ask your team an open ended question about ideas for improving the project. As the team posts it ideas, members can vote up the ideas they like the most and provide commentary on its implementation. Over time, you have a nice prioritized list of improvement activities for your project. As you implement these ideas, the burning need for a retrospective may disappear.

Velocity gone wrong #1: Done is not done

by Danilo Sato

Dan North wrote an interesting post about the perils of estimation, questioning our approach to inceptions, release planning, and setting expectations about scope. This made me think about the implications of those factors once a project starts, and I came up with some anti-patterns on the usage of velocity to track progress. This is my first attempt at writing about them.

Before we start, it’s important to understand what velocity means. My simple definition of velocity is the total number of estimation units for the items delivered in an iteration. Estimation unit can be whatever the team chooses: ideal days, hours, pomodoros, or story points. The nature of items may vary as well: features, use cases, and user stories are common choices. Iteration is a fixed amount of time where the team will work on delivering those items. Sounds simple? Well… there’s one concept that is commonly overlooked and that’s the source of the first anti-pattern: what does delivered means?

… (read more at Danilo’s blog).


Download this Geek Snack episode here.