Team Focus (Team First Mindset)

A Code Review needs to be prioritized, and a Feature Partner needs to be able to give their task enough attention. This pattern describes an approach to ensuring that reviews happen in a timely manner and provide the most valuable feedback.

Too Many Threads

Good feedback on design and code requires context and responsiveness, and the team should be able to provide that if the work is planned appropriately. But two things often get in the way of this:

When planning work, it is tempting to select work so that each team member is working in parallel on independent tasks. More parallel independent streams mean more tasks can get done, but having too broad a spread of work can slow the team down by making collaboration and demonstrating value harder. When team members feel responsible for their work over a team goal, overall delivery suffers.

Some tasks require knowledge that the current team does not have, for example, setting up integrations with an external, system. In these cases, an enabling or support team could help, but unless that team shares the same priorities, their support can’t be planned for.

Sometimes, work items appear to be isolated tasks, and many of these tasks are suitable for one person and may not be complex enough to require a team to design and build them. On the other hand, communicating ideas and getting feedback has benefits: it makes for better results as one can tend to find it hard to step back from an approach, and it provides redundancy so that someone else can support the work. Even for small tasks, there are benefits to getting feedback from someone who has context and collaborates promptly. And when a task can’t be related to some business goal, the team should question why it’s doing it.

Planning for high individual utilization on tasks leaves no slack, making it hard to address issues that arise. When an issue arises, team members might feel mixed priorities: working on the task they know they can do quickly versus resolving a broken build, for example.

Not all teams are cross-functional. But a team could collaborate to deliver a feature to share goal context and interfaces.

When work is organized in terms of tasks, a team can focus on tasks and lose track of the goal of a development cycle. I’ve worked on Scrum, where the Kanban board consistently looked fine, with many completed tasks tracking to where they should be, given how far along we were in the sprint. Yet we frequently had nothing to demo because essential “connector” work was not done, or worse, not planned for.

If the goals and global priorities of the team are not clear, some of the critical tasks might remain undone, which can result in:

People can switch between work intermittently, but too many threads make it hard to work as a team.

One Shared Goal

** Start each development cycle with a clear statement of Team Focus — a shared goal. Communicate the team goal and prioritize finishing work in progress over individual tasks. Evaluate progress towards the goal at a daily standup. **

Start each development cycle with a Team Focus that gives everyone context and prioritizes finishing work in progress. One heuristic to follow is asking, “How will we demonstrate this work?”

A Team Focus is similar to the Team First Mindset mentioned in Team Topologies {Skelton and Pais, 2019 #176839}, though without the product goal element.

Plan work so that a feature gets done end to end, so people with skills across the stack are working towards a shared goal. Even if a mobile developer can’t give deep feedback on some aspects of a backend decision, they can be an excellent sounding board for tradeoffs. This focus includes anything that gets in the way of delivering a feature, including operations and infrastructure issues.

There are two aspects to this:

In Scrum, this is captured by a Sprint Goal, though even in a Scrum process, teams sometimes plan “issues” and “tickets” with the result that the big picture gets lost.

One approach is to start each development cycle with the question:

“What would we like to show at the end of this development cycle?”

Reviewing that question daily will help the team focus on completing features, including reviewing and integrating work. And clarify that “demonstrate” means “show the current state of the work” and not “make a polished sales presentation.”

In some cases, even with a common team focus, some aspects of a project may benefit from some level of specialization. In this case, it is best to have more than one person involved in specific design discussions and reviews. This can be addressed in a number of ways, in particular using designated “feature partners.”

Team Focus can also be related to incentive structures and other aspects of people management, which are beyond the scope of this book. But it is worth considering those issues as well.

Cautions

Don’t confuse team focus with inflexibility. Many teams can accommodate small interruptions; the key is transparency. For example, if the team has a role in production support, allow for contingencies in the plan to accommodate issues based on historical trends, and be clear about the level of issue that takes priority over the Team Focus.

Next Steps