I’ve worked with lots of agile #teams, and some of the symptoms of a well functioning high-perfoming teams that I see are:
👇
👇
They start their daily standups on time.
They tend to laugh a lot and have fun.
Everybody in the team gets to express themselves.
They correct and edit each other when they go off track.
They try out new things with appetite. But they are quite willing to admit those things didn’t succeed.
They often don’t care very much if it looks like they’re working hard.
They encourage each other to leave on time.
They talk about how “we built” or “we failed”, rather than “I built“ or “I failed”
They have lunch together, or some other time within work hours where they talk about other things than work.
They welcome more junior members of the team, and enjoy mentoring them.
They have inside jokes.
They share responsibility for communicating with outside stakeholders.
They don’t agree on everything.
They debate between short term benefits and long term strategy. They reach compromises.
They question each other on topics like accessibility and inclusivity in design and development.
When they finish a task, they check if they can help someone else finish theirs.
There’s room in good teams for extroverts and introverts. And those in between. Team members are aware of their needs and communicate those to others.
I’ve seen some great teams have some seriously stubborn people in them. They can be great when the team needs reminding of why they came up with a certain rule: specifically so the team wouldn’t compromise when they were in a hurry
Good teams often fight for independence to make their own decisions
They ask “why” a lot
They discuss the users of their products every day, and the user experience is viewed as everyone’s responsibility
If they are remote, they try new ways to make everyone equal, even if it means compromising the experience of those people that are in a shared space
They are not dogmatic
Testers and designers are included in discussions of estimations and backlog refining
They respect agreed decision making structures, but argue their points
The people are not too similar to one another. They think about problems from different angles.
If someone on the team is ill, the others figure out how to get by without that person.
They have quiet time. In whatever amount is valuable to them.
They don’t interrupt each other. They take equal turns in speaking.
They get each other tea/coffee/water.
They have one-to-one chats with each other to discuss points of agreement or disagreement.
They know each other’s personal and professional goals and aspirations, and try to support them where possible.
They are not all equally skilled at everything. But they try to work on things where they can learn.
When people pair on a task, the less experienced person is usually the “driver”
Senior team members ask for advice and feedback from more junior team members.
They don’t have to give positive feedback every time they give negative feedback.
They thank each other for favours, for tea, for good ideas, for bad ideas, for observations…
They use the products they’re building
When someone has an idea, other team members build on it and add to it
They accept that people have “off” days
They are generally resilient when it comes to change - including change of direction, goals and vision
They can work quickly, but it’s not always crunch time. There is a sustainable cadence to work.
They regularly talk about how they work together, and try to improve that
Team members generally know what every other team member is working on, and what kind of issues they’re having
They encourage each other to share work early, rather than wait for it to be “perfect”
They have some shared values or principles that guide their interactions
They try new tools and methods quite easily
They might defend each other to people outside the team
Before they ask for feedback or reviews from other team members, they read through their own code/work
They have time to / they prioritise automating tasks that are not valuable
They talk about technical debt, and teach stakeholders about it
They don’t grow too quickly
The work they do feels important
They argue
They talk about how well they’re doing compared to expectations. If the estimates turn out to be off, that’s not a disaster
They take turns dealing with boring or time consuming tasks
They are interested in each other personally
They talk about problems without talking about people’s characters, rather they focus on the work
In meetings, they put their phones down or close their laptop lids when they’re listening
They have a say in who joins the team
They have shortcuts for common communication (like signals for when the conversation is derailing, or when they’re losing focus)
They don’t mistake fun for a lack of discipline
They consider different communication styles. Meetings are not just held so the loudest speakers are heard the most.
They care that other team members and stakeholders understand the work they’re doing
Documentation is updated whenever errors are spotted, by the person who spots the error.
Team members feel a shared sense of pride and ownership of their work
It’s not ok to notice a problem, and not do something about it, even if it’s not in an individual’s immediate area of responsibility
Developers participate in sketching sessions, designers understand how git works.
Team members reach out to their personal networks to ask for help for other team members.
Everybody tests
Team members let each other try things out even if they think it will fail (sometimes, if constructive)
They notice when other team members seem worried or down. They ask about it.
I could continue, but I need to sleep. 😴
Remember: this is a list of observations that correlate with well performing teams in my personal experience. It doesn’t mean that your team is not awesome even if you don’t do these things. ❤️
Remember: this is a list of observations that correlate with well performing teams in my personal experience. It doesn’t mean that your team is not awesome even if you don’t do these things. ❤️
Good teams generally start their standups on time.
It shows respect for fellow team members who would otherwise be waiting, and it sets a purposeful intention for the day. The actual standup often contains inside jokes, laughter, music. But it starts on time.
It shows respect for fellow team members who would otherwise be waiting, and it sets a purposeful intention for the day. The actual standup often contains inside jokes, laughter, music. But it starts on time.
When team members edit and correct each other, it might be a small comment like “let’s talk about that later” during standup, or adding to another person’s explanations. It shows a shared sense of ownership of communication. It’s not just about speaking.
Taking credit for success together by saying “we built” and “we fixed”, also makes implicit promises that team members won’t hang each other out to dry individually when they fail.
Thinking about changes as experiments with hypotheses and measurable success criteria makes it easier to make those changes. And to reverse them if they didn’t work.
Solving technical or software problems doesn’t always get done at a keyboard.
But somehow there’s still a prevalent view in some orgs that development = typing.
But somehow there’s still a prevalent view in some orgs that development = typing.
At @ustwo many (most?) teams have a weekly half-hour “fika” break - coffee and cake/snack - during which they just try to get to know each other better. It’s a good habit, and almost always comes up as one of the highlights in retros.
At some point of experience, we need to start thinking about how to scale our skills beyond our own work. Mentor others before your own marginal rate of learning starts to slow down.
Let’s not talk about MBTI’s (Myers-Briggs) validity, but taking a test like 16personalities.com as a team, and reflecting on which things ring true, can give team members a vocabulary to communicate better about themselves.
Also, I’m totes ENTJ and capricorn. Hmu.
Also, I’m totes ENTJ and capricorn. Hmu.
Many teams limit the number of items in progress. To start, that number can be the same as the number of team members (which is already a stretch for many teams). As they get better at collaborating and finishing, the WIP limit decreases (sometimes down to 1/2 of the team size).
And then there’s the old:
STOP STARTING, START FINISHING
STOP STARTING, START FINISHING
As a coach, it’s often my job to argue for more #team independence. I often start with:
- can the team approve their own holidays?
- can they decide their own sprint length (or no sprints)?
- can they make decisions about which tools they use?
- can they decide working hours?
- can the team approve their own holidays?
- can they decide their own sprint length (or no sprints)?
- can they make decisions about which tools they use?
- can they decide working hours?
