Keeping focus as a development team

As software developers, we have to deal with many different tasks daily. Not only tasks, but different applications, with different stakeholders and priorities. Also we tackle bugs to technical debt to feature development over time.

Today, most of us work in sprint-driven environments, using Scrum, Kanban or Scrumban. We plan for short cycles, yet fill these sprints with many tasks and topics. Thus resulting in jumping between topics, many times juggling with tasks in parallel.

How do we keep focus as a team when there is so much going on?

I'm sharing my learnings and practices in how to identify the need for more focus and applying a Focus Sprint for immediate improvement. Focus requires a lot of discipline and a clear priorities.
From a developers perspective there are three main areas influencing our focus:

• Team Level (Product Team, Feature Team...)
• Personal Level (You)
• Business Level (out of scope)

Our problem

Multi-tasking is bad, it can even get to a point where your brain is not even able to do any deep thoughts. As software developers we are dealing with a lot of different problems at the same time (bugs, features, technical debt, architecture, etc.). So by design, we can lose our focus as we are tackling different problems at the same time.

One way to solve distractions as a team is to do a Focus Sprint.

The goal is to have one top priority topic/epic/feature the whole team focuses to finish within the sprint.

My personal Example:

We wanted to run an A/B Test and we know that in the past it took us often more than one sprint (two weeks) to get everything in place. Over a couple of retrospectives, we discovered two root causes slowing us down. One was about hidden dependencies to other teams and the other about too many things in parallel.
We decided to drop any task except finishing the A/B Test. We also planned and discussed dependencies before we started working.

The result was that we finished as a team 50% faster and had a couple of days left to work on other stuff besides using more than one sprint in the past.

How can you make sure that you're not loosing focus ?

Team Level

There are different ways to improve as a development team. For us, small improvements, changing our habits, had huge impact on our productivity as a team. A Focus Sprint is one way to get stuff done. For me, it is a way for a Team to act on issues immediately and get back on track. Use it as a great opportunity.

Here is a list of things you do as part of a Focus Sprint:

One Topic = One Sprint

The core idea is to commit one topic within one sprint. Don't commit to all the things you're planning for. Only plan to finish the most important feature / a-b test / tech debt which will enable the business. Agree that you will not put any different task into your sprint backlog until that one topic is done. Thus a topic is still big and there are more things involved in a Focus Sprint which you need to adopt.

Name the sprint

Define a name for each sprint / work week. You can make it funny, but make it clear. A new feature, e.g. "add color filters to product search" your sprint name could be "Color Filters" or "Coloring Search".

Clear Prioritization and Impact

In Scrum, the first item on your Sprint Backlog is the most important one people start working. The order is the priority.
Don't jump to any Bug immediately. Remember, if someone asks for a Bug fix, say No, refer to the Focus Sprint and say you will work on it after that. Customer Impact should be your KPI.

Limit your Work-In-Progress

Too much Work-In-Progress (WIP) is bad. It is a blocker. Limit the amount of WIP Tasks. If you are 5 people working, limit WIP to 5. One developer one task. When you're blocked, try to remove it first and if it takes longer move it a separate "Blocked" column and continue.

Slice your tasks

Make sure any Ticket / Issue has a scope of a day or two. Have regular meetings or make it part of your Planning to discuss how complex or big a task is. Slicing also helps in identifying dependencies.

External dependencies

Identify external dependencies before you start coding. Refine your tasks before you start working on them. A button is always more than the HTML Tag. Talking about topics and tasks before you start helps identifying dependencies early. This allows you unblock yourself from the beginning or plan different.

Do Retrospectives

The best way in identifying issues, related to focus and other things, is by doing regular Retrospectives. A Retrospective provides a regular way of reviewing the past as a team. It is the meeting I see many developers skip first, yet we should do the opposite. How can we improve, talk about focus, if we don't talk about it?

There are many resources how to do them and what kind of. The main purpose of it is pretty simple:

• What worked well for us?
• What did not work well for us?
• What actions can we take to improve our process going forward?

Retrospectives allow teams to talk about problems. Anything that didn't work well, needs to be addressed. Use post-it's and pen's and give everyone 5 minutes and see how fast people share issues and problems.

Individual level

On an individual level I shared some steps to improve productivity and have deep work.

In an ideal case you or someone from your team would raise the issue of too many things on our plate either in on of your planning meetings or reviews.
Yet, as humans, we can easily end up in a cycle of keeping ourself busy. There are different reasons for this:

• Heroism; if we really manage X topics in parallel, everyone will look up to us
• Frustration; you raised the issue multiple times but nothing happened.
• Keeping busy and heads down-under aka "cover your ass".

This is one of the reasons why I think doing regular retrospectives are a good to way to provide a space where people can share issues and problems from the past easier.

Conclusion

A Focus Sprint is a good way to show business and product people that clear priorities and less topics during a sprint can improve performance significantly. It is a tool, to help the development team show business that there is a problem in the Ways of Working.
It can be that your team has a dysfunction, wrong expectations or unclear business requirements.

When you decide to do a Focus Sprint try to understand the forces that created your need for this. A Focus Sprint is a great way to get back on track as a team. It is not a one time fix tool and when you see yourself constantly asking for another Focus Sprint, go deeper.

Credits

This post is inspired by a discussion with @sharifsbeat and this Tweet :

Thanks for having these discussions.