On retrospectives

When things slip, a typical reaction is to add processes especially for tracking and monitoring. Just take the overhead effort for effort tracking for example. I’ve been in a lot of projects that at one point or another have gotten so delayed. A knee-jerk reaction is to have the team prepare more reports — daily status updates from everyone, summarized daily progress reports from the leads, reports for upper management, reports for client, etc, etc. This has its benefits — it provides more visibility on what’s going on in the project, and it can pacify stakeholders since it gives the impression that you’re on top of things. What it doesn’t do is get more of the actual needed work done. It doesn’t get more work coded. It doesn’t get more tests executed.

dilbert-19950217

Instead of just diving into the “more reports” bandwagon, what I’d like is for the team to look into how we’re currently doing. What’s working for us? What isn’t? What do we need to do differently? These are questions that usually get asked in a retrospective meeting. If we google “retrospective”, a definition that turns up is “looking back on or dealing with past events or situations”. Reflecting on what has happened is but a part of it. In retrospectives, you also try to identify what you need to bring forward to keep your project successful or to recover so that your project will (hopefully) be successful.

I think I can pretty much go ahead and do a little retrospective on my own. We all can do it individually. But that just won’t suffice. I can plan all I want but if the folks who will execute are not aligned with the plan, then the plan will just fail to materialize. And you can come up with all brilliant sorts of ideas and workarounds but if you can’t get the other guy to execute then it wouldn’t matter so much (but I’ll credit your brilliance, of course). Retrospectives need to be a team thing. WE need to come up with plans for improvement that WE are ALL willing to execute or follow through. In the end, there is no one else to drive the project’s success but US as a team.

About these ads

One thought on “On retrospectives

  1. Pingback: Testing Bits – 11/24/13 – 11/30/13 | Testing Curator Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s