Why it’s ok for teams to work differently to each other

I’ve been talking about the autonomy and metrics of teams this week, so I thought I’d write some of it down.

We have a lot of agile teams of varying makeup and although there are similarities between them, the one thing to note is that they are all different and they have autonomy over the way that they work.

They all have someone that plays the product manager role (the vision owner) and someone that plays the delivery manager role (the person with a focus on delivery), they all have a moment in the day when they do a brief status meeting (a standup) and regularly review their processes and dynamics (retrospectives). But aside from that, they all work in the way that suits them best and helps them move towards their goal.

Different teams / different approaches

Our teams vary a lot; from those that are developing software, to those that are writing policy and setting up initiatives. Some of our teams use time-boxed iterations (sprints), which come with sprint planning, some use more flow based task management. Some teams use traditional story formats and others don’t, with that some use story points and velocity and others don’t estimate and may use other metrics, like cycle times. Most teams have their own variations of workflows depicted by their task boards. We don’t impose a “one way” of working for any team and this is important. It’s important because these ways of working are really only important to the team.

Supporting teams as an organisation

For an organisation that the team belongs to, the only thing that should concern them is: Is the team able to deliver against the agreed goal and how can I support that?

If the goal is to get working software into people’s hands, it’s not important to those people how you do it. They get value when they get the software; that’s the bit that’s important to them.

Trying to standardise ways of working may force teams to work in ways that take them away from the goal of delivering software to users, so is counter-productive.

Delivery metrics for teams

Team metrics help a team to understand if it’s working to a sustainable pace and helps to identify where there are issues. For example; velocity is not an indicator of how fast a team is going, but simply a check to see that it is going at the same speed throughout the project. Using it as a productivity metric will only force the team to focus on reporting more velocity, and less on achieving the goal.

Goal based metrics for organisations or clients

So if the things that concern an organisation or client are:

Is the team able to deliver against the agreed goal?

Then it is important to the organisation: to understand what is being delivered, which they can do by seeing the actual work) and how is it moving us towards our goal, which would have it’s own measures.

How can I support them in the delivery of the agreed goal?

Then they should be asking that question of the team: what do you need to achieve the goal, how can I help you meet it and can I remove anything stopping you.

Simply put: make sure your teams have autonomy with alignment to a goal and they are supported in this.