Working as a team

Moving from individual work to team work

Intermediate

difficulty

Stage 2

Agile IQ® Level

Teams

VALUES

Introduction

Part of a Scrum Master’s role is to support people in the agile team to:

Work as a team over working independently on their own functional work.
Help Product Owners to set objectives.
Help the team to define their goals that will contribute to the Product Owner’s vision.
Work collaboratively and collectively to achieve those goals.

"A collection of individuals who are interdependent in their tasks, who share responsibility for outcomes, who see themselves and who are seen by others as an intact social entity embedded in one or more larger social systems (for example, business unit or the corporation), and who manage their relationships across organizational boundaries. (Cohen & Bailey, 1997, p. 241)"

John Doe

Why teams fail to be a 'team'

New agile teams can fail to form as a team when:

There is no Product Goal or Vision: The Product Owner hasn’t really got a goal or a purpose for why the team exists, why they’re working together, and what impact the team will make in delivering products and services to its stakeholders, clients and users. Without a goal, the team are left just be a ‘feature factory’.
There is no Product Owner: Customers and stakeholders go directly to individual team members when they want something done.
The team is management-led instead of self-managing: Managers set oall and tasks for individuals believing that this is the most effecte way to lead a team. Unfortunately, it silos the work and creates multiple personal work goals instead of a single team goal.
Functional siloing: People only want to do their own work, e.g. “I’m a developer and so I only do coding”.
Backlog Items are functionally defined: There are UX Stories, BA Stories, Test Stories, etc. All items in the Product Backlog should be clear about the stakeholder need, the functionality they want, the service they need. Backlog Items shouldn’t prescribe work for specific members of the team, based on their skills or job title.

Whose job is it to help people become a team?

Agile teams work best when they are self-managing. Their focus isn't on individual tasks, like development or testing, writing copy or publishing social media posts, but what will it take to deliver an Increment of value to users and stakeholders. This way of working can be hard for people who are used to just 'getting on' with their own work and not helping others with a focus on achieving team-level goals. Helping the team work in this way involves improving the cross-functionality of the team. This is one of the Scrum Master's key areas of resonsibility.

Things to Try

Don’t start work until other work is Done

When the development work is finished, there is always temptation to just start the next User Story. Instead, support everyone to brainstorm what’s needed to get the work that’s in-progress to Done BEFORE new work is started.

Stop delegating tasks

Create work for the team and then support the team to come up with a plan of who does what tasks and when.

Support and coach managers to set goals and Product Owners to manage the work that’s needed to achieve those goals.

Stop tracking tasks. Track and report on progress toward goals. Agile OKRs may also help here.

Stop writing ‘functional’ Stories

Agile teams don’t have BA Stories, Test Stories or UX Stories.

Best practice is to write Product Backlog items from the perspective of the user or stakeholder. It defines who they are, their context, needs, and what they want to get out of the feature you’re building or the service you’re providing:

As a care giver
I want to see a list of service providers
So that I can make an informed decision within my budget

With this perspective, a cross-functional team then works together to plan its delivery:

What user research do we need to do?
What functionality is needed to fulfil this need?
How will we build a technically sound product?
How will we test that it works?

This approach to writing the work for the team helps create:

A shared goal.
A shared plan of action.
A way to deliver value as a team over just focussing on their own individual parts of the work based on their functional role.

Set Shared Goals

Teams perform better if the goals that guide work are clear, specific, and challenging rather than vague, ambiguous, and unchallenging. Goals activate motivational mechanisms that stimulate performance. Four stimulating mechanisms are: direction, effort, perseverance, and strategy (Latham & Locke, 1991, 2013).

Reinforce the team’s focus on its goals during each of the Sprint’s events:

Retrospectives: Help the team set goals, targets and actions for improving an aspect of the whole team’s agility. E.g. Sprinting, product health, stakeholder engagement.
Sprint Planning: Come up with a few sentances that give the team focus for the work for the Sprint. This is the Sprint Goal. Achieving the Sprint Goal is the primary concern. Finishing the Backlog Items selected for the Sprint should serve the Sprint Goal and not be a goal unto itself.
Daily Scrum: Talk about progress toward the Sprint Goal and what you can do in the next 24 hours to get a bit close to achieving it. Don’t give a status report.

Improve Cross-functionality

Agile teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Agile teams are designed so they don’t have to rely on people outside of the team to deliver value. Relying on people outside the team to, for example, approve work or provide quality assurance, delays the delivery of value.

Pairing: Pair developers with testers on a single piece of functionality. Get them to work closely together at the same computer throughout the delivery of the item.
Formal knowledge sharing: Take turns to formally teach other members of the team your particular capability area, e.g. teach developers the tricks and traps on how to test and then have everyone do some testing in the Sprint.

References

Cheney, G., Christensen, L. T., Zorn, T. E., Ganesh, G. (2011). Organizational communication in an age of globalization: Issues, reflections, practices (2nd ed., pp. 215–251). Long Grove, IL: Waveland Press.

Delarue, A., Van Hootegem, G., Procter, S., Burridge, M. (2008). Teamworking and organizational performance: A review of survey-based research. International Journal of Management Reviews, 10, 127–148.

Loerakker, B., and Kirsten van de Grift, K. (2015). The effectiveness of self-managed teams and self-leading teams measured in performance , quality of work life and absenteeism

Sutherland, J. and Schwaber, K. (2020) The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game.

Van der Hoek, M., Groeneveld, S., Kuipers, B. (2016) Goal Setting in Teams: Goal Clarity and Team Performance in the Public Sector.