We’ve all heard the reports that tell us how multi-tasking is not effective, how context-switching causes us unrecoverable down-time. We know from this that we need to be more tightly focused on a single goal (per sprint), one that we can organise our work around, one that more easily helps us know that what we’re doing will deliver something of value. That’s good as far as it goes.
Now I’m going to mess with that. I’m going to suggest that each and every sprint should have two goals.
One and only one of those should be aligned to the teams purpose; that is, if they are shoe box team, then every sprint, their first goal should be how they can release the next increment of a great shoe box experience. So far, so good, I hear you mutter.
The second goal should be for the team, what they want to improve this sprint about the way they work and they way they behave.
We know that, to be effective, agile teams of any stripe need to use empirical processes of inspection and adaptation. The inspection part of this is normally ‘enshrined’ in the retrospective, a time set aside at the end of each and every sprint to reflect on how things went, what the team want to stop, change, or start doing.
All too many teams, however, stop there. The retrospective is a great session to vent, to rant, to detox. People return to their desks cleansed of whatever went wrong in the last sprint, feeling fit and ready for the next onslaught.
For such teams, they often find the same topics coming up in their retrospectives, time after time, and wonder why. “It must be them”, you often hear; pointing the finger of blame at something or somebody outside the team.
The answer lies within us
With some teams (or maybe most or even all teams), however, the root cause of the impediment lies within actions the team has taken. If the problem keeps recurring, then that’s because the team haven’t changed anything. You the know the saying, “the definition of insanity is doing the same thing and expecting a different outcome“.
If the team feels that an issue is a problem, then to be effective as a team, they need to understand the root cause and to ‘fess up when it’s something they did. However, while confession might cleanse the soul, it won’t change outcomes unless we change our behaviours.
Changing behaviours takes time, effort, and commitment; and it is for this reason that effective teams carry a second goal into the sprint … one of ‘team improvement‘. Ideally this is posted on the team’s board so that it is clear and obvious to everyone that they are focused on delivering and on improving.
What if the answer is ‘out there’
Of course, it could be true that the root cause of a problem lies outside the team; there might be an organisation impediment, there might be a team upon whose work they are dependent and who are continually late in what they provide, there might be a manager who continually gives additional tasks to people in the team that steals time from their sprint goal.
When such things happen, there is often little the team can do, or think they can do, ‘in the moment’ to fix it. That’s the purpose of the retrospective, to consider such moments and what lesson may be learned from them.
If the challenge is really outside the team, then the scrum-master should escalate this and endeavour to see it resolved. That, however, can take some time to happen. So what can teams do about that? Do they just resign themselves to seeing the same problem sprint after sprint?
As with any problem caused by someone else, while you cannot change the other person you can change how you respond, how you work with that other person ‘in the moment’ to resolve it, or how you bring that work into your team and work a different way so that you are not dependent.
This could be as simple as an agreement with the team that, when that mischievous manager turns up with a handful of ad-hoc tasks for the team, they have a standard phrase they all use to deflect the problem. Ranging from, “sure, but what of the work we’ve committed to for this sprint do you think we should drop to do this instead” through to “add it to the backlog and we’ll let the product owner prioritise it ahead of our next sprint planning”.
Such an agreement could also be the team’s chosen improvement goal for the sprint.
Two goals for success
So, effective teams have two goals per sprint. One to deliver against their purpose and one to continually improve. In this way, effective teams mature toward becoming high-performing … but that is a post for another day.
What are your views? Do you agree or do you think teams should stick to one and only one goal per sprint? I would be keen to hear what you think.
