These days, “Agile” and “Scrum” have become somewhat synonymous in various contexts. Nevertheless, self-reflection and the practice of adjusting team behaviour is key to most endeavours in life. Neither Scrum nor Agile can claim to have invented this practice.

The Scrum Methodology (http://scrummethodology.com/) is perhaps the most in-vogue codification of this practice in the form of its “Sprint Retrospective meeting”:

Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behaviour and take action to adapt it for future Sprints. *

Given this, one would expect constant improvement to be characteristic of most “Agile” teams. However, the truth is that many fail to achieve this goal.

Sometimes this is due to problems with motivation. Often the team doesn’t feel ownership over their own process, or feels that essential problems are discounted by persons outside the team who control work assignments and prioritisation.

However, teams need to accept that attributing blame to people outside the team is rarely helpful, and that there is much a team can do to improve their situation, even when the context is far from ideal. Sometimes the team is at fault.

Give your Retrospectives teeth

If you’re going to make real improvements, you need to start getting real about changes. It’s no good thinking up improvements and then ignoring them. You need a way to track progress from sprint to sprint - some way to quantify how well we’re practicing what we’ve said we’ll do to improve. Our product works by giving your retrospectives the teeth they need to have an affect. Its a habit which doesn’t need software, but software can help you develop the habit.

Setting expectations

Some developers assume that they’re doing ok and don’t realise that they’ve stopped pulling their weight. Others can be so naturally driven that they ignore the needs of us mere mortals to discuss expectations and agree goals. Good communication, and shared commitment, are at the core of “Agile” philosophy, and if you’re doing Agile, communication should be your primary tool.

With our product, the team decide by consensus the types of behaviour which should be encouraged (or discouraged), and assign points accordingly. This makes the team the arbiter of how they want to achieve their business goals, and helps people of varying levels of drive and motivation start share a set of expectations.