New Adventures in Technology

A couple of months ago I gave a series of talks on creating team charters. As part of my preparation for this piece of work I asked myself a number of questions about what a team actually was, and what sorts of questions teams should be asking themselves regularly. Some of this content was used in the talks, but I’ve tried to make this article more about teams than team charters, as I’ve written and talked about these a lot elsewhere.

What is a team?

A team is a group of people who collaborate to deliver value. Value is anything that a customer would pay for.

A team doesn’t have to all report to the same person, or do the same kind of work, they just need to be able to combine their skills and expertise in a way that delivers something that someone else finds valuable.

Why does the team exist?

Each team should understand why is exists, and be able to articulate that in a short phrase. This should be a mission statement (what you do now), but may also incorporate elements of a vision statement (what you hope to achieve).

You should also understand who your stakeholders are, both the people you deliver work to, and the people outside the team who you depend on for things that you need. Ideally a team should be able to control everything it requires to deliver value, but this is unlikely to be the case in most organisations, and you are likely to have stakeholders who provide data centres, networks, offices or financial processes. Think about everything you need to do your work, and work out where it comes from, and how to get enough of it for what you need to do.

What skills does a team need?

That depends very much on what the team are responsible for delivering, but can be split into 3 main categories:

• Subject matter expertise
• Organisational skills
• Leadership and management skills

These skills should be present across the team, but it’s fine for one person to have aspects of all three. What you don’t want is people who don’t have any of these skills, as they will find it harder to contribute meaningfully to the team.

How many people should be in the team?

That very much depends on what skills the team needs, and how those skills are distributed between individuals.

I like teams of 4-6 people, because they are small enough to make collective decisions quickly, but large enough to realistically contain a good mix of skills and experience. I may also add 1-2 interns, graduate trainees or apprentices, especially if the work being delivered would benefit from the unique experience people at the start of their career will bring. It’s also a good way to ensure that people starting out are being given a positive experience about what it’s like to be in a team.

How do we empower a team to be self-organising?

A self-organising team understands what it is there to do, and receives work from customers rather than managers. It prioritises work based on what value it adds to one or more customers, but also improves how the work is done so that valuable work is delivered more often. It is free to make decisions on how the work is done, providing any institution-wide restrictions are factored in. The larger the institution, the more likely a team will be restricted in some of the tools it uses, or in where and when it works, but it is still worth thinking about these things and contributing expertise towards redefining the institutional standard, rather than just using something different and then struggling to collaborate with other teams.

Working in this way can require a bit of unlearning, especially for people who hold leadership or management roles. An understanding of the key principles of Agile can help with this, as very often ceremonies associated with Agile (especially Scrum) are used to plan and deliver work in a self-organising team.

How does leadership and management work in a self-organising team?

In a traditional team you would expect the team manager to provide all (or most) of the leadership. management, and organisational skills, but also a fair amount of subject matter expertise. In an agile team we still need all of those skills, but they are more likely to be split more evenly between different team members.

How this might work:

• One person who has a primary responsibility for ensuring that the work the team does continues to provide value to customers.
• One person who has a primary responsibility for providing an environment for the team to do their best work.
• Several people with subject matter expertise, who also have enough leadership, management and organisational skills to ensure that they can deliver within their subject area without hitting blockers on a daily basis.

Ensuring the skills are more equally distributed helps the team when one of more people are on holiday or otherwise unavailable to work. It means that a team is better positioned to deal with things that might slow down delivery, and that the team is not reliant on one person for many different things.

What meetings should the team attend?

There are a number of internal meetings that we find useful:

• Daily stand up, to ensure that we have a collective understanding of what we are doing each day, and that we can identify anything where we might need help
• Sprint planning, so that we understand what is being delivered in the next 2 weeks, and who is doing what
• Retrospectives, to enable us to scrutinise how we work, and suggest improvements that can be fed into the next cycle

We still conduct 121 meetings, but these are less like status update meetings, and more about personal and professional development. Meeting every day to talk about our work doesn’t make 121 meetings less important, it just means we can focus them more effectively.

What about all those other meetings we attend?

Review all meetings and regular time commitments to ensure they add value to customers or directly contribute to improving how the work is done:

• Why do you attend the meeting?
• What contributions do you generally make?
• What outputs do you get from the meeting, and are they valuable?

These questions should help identify meetings that could be dropped in order to free up more time for collaboration and individual contributions.

It is expected that people with leadership and management responsibilities will attend more meetings that individual contributors, but that in general there will be less meetings than in a traditional hierarchical team. Managers should be protecting their teams from meetings where possible, but this does not mean that people should stop collaborating with other teams; just that they do it in a way that only the people who are directly contributing to the collaboration are involved.