Team Focus

Having a Team First Mindset and a Sprint Goal can help to integrate code quickly.

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 requires context and responsiveness. There is often a desire to try to do more, which means spreading effort more thinly but doing so can make it hard to review code with all the context, leaving people idle, multi-tasking, or adding to open Pull Requests, with the result being that less gets done over a period of time.

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.

Many 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.

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:

• Little product value delivered at the end of the cycle or 

• The Mainline will become unusable, slowing the team down.

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.

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:

• The team having a shared goal, even if there is disparate work

• A Clear statement about expected interruptions: Production issues etc

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 each day will help the team focus on completing features, which includes doing reviews 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.” 

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

• A Team Focus derives from the tasks in one or more Product Backlog Items. 

Notes

• Team Topologies uses the phrase Team-First Mindset for a similar concept. That name doesn’t capture the product goal element, but might be a better name for other reasons.

  • 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, too.