Posts Tagged “goals”

Agile teams use the retrospective to collect a set of start, stop, and continue actions at the end of each iteration. The point of this technique is to collect feedback as a team and focus it (through one of the above verbs) into actionable steps toward improvement.

But retrospectives often produce a dozen or more actionable steps, and teams can grow nauseous from seeing the same things show up retrospective after retrospective with little or no progress made. So, how does a team break this cycle?

By prioritizing only one or two activities as goals for the next iteration.

It’s hard to remember to work on a dozen (or even half a dozen) things at once, even when you don’t have an iteration of work to complete at the same time. Remembering to focus on one or two goals is much easier, especially when your entire team is also thinking about those same goals.

Finally, the team needs to close the loop by discussing the outcome of each goal in the next retrospective.

  • Did everyone really take the agreed-to steps to meet the goal?
  • Was there a beneficial outcome?
  • Should the team focus on the same goal in the next iteration?
  • Was the outcome different than expected?
  • Should the team take different steps to achieve the goal?

And there you have it: continuous improvement.

Comments No Comments »

This blog is the result of a great question asked in the comments of my last blog entry. Quinn asks:

“Of course we get side-lined by an occasional production support task or an overly optimistic lead developer that bites off more than we can chew…. I feel that it’s a huge slap in the face when you are programming like a ferret and don’t get to 1 or 2 stories out of 25-30 in a 2 week iteration and the PM or IT Director is “disappointed” that you have carry over…. And thus I bring the question to you–what is the TRUE measure of success?”

Great question! Read the rest of this entry »

Comments No Comments »