What makes a good team?
Is there such a thing as a good sprint?
Do they look the same for everyone?
The background
In order to solidify our understanding of best practices and hone our algorithms from an expert point-of-view, we conducted months of research. We talked with engineering managers across companies big and small, about their teams and their work. While their measures of success varied, they all shared clear themes that emerged in our interviews.
In Part 1 of this two-part series, we will talk about sprints—and share potential indicators that teams and managers can prioritize (or avoid) as they work to increase their engineering team effectiveness.
What to avoid ❌
Let’s talk about bad sprints
5 things you want to avoid for effective engineering sprints:
Nearly all the engineering managers we talked to agreed that ineffective sprints share some common flaws. If these hit close to home, rest assured that smart practices can course-correct where you’d like to go.
1. Bad sprints lack clarity. When expectations aren’t clear, teams thrash around and waste time on work items without a specific goal. It’s much more difficult for team members to focus during Deep Work time when they aren’t clear on what they need to accomplish. Enter: lots of shoulder taps, Slack chatter, and unanticipated meetings to get a clear picture.
2. Bad sprints allow “scope creep.” If sprints make room for shifting priorities, mid-sprint design changes, or additional work after planning is complete, they can throw progress off-balance. Context-switching and missed deadlines are frustrating enough, but scope creep can also lead to more bugs, creating more work for the team down the road. Ultimately, it comes down to a pressure to accomplish a higher volume of work, which compromises quality.
3. Bad sprints include a high amount of context switching. Related to scope creep, an increase in distractions and interruptions can lead to teams feeling randomized, working in different contexts, and each needing additional ramp-up time.
4. Bad sprints have too many interdependencies. Working on too many tasks with too many interdependencies is a recipe for disaster. This will likely increase a team’s chance of getting blocked, and working without all the information they need. To combat this, teams will usually schedule more meetings and lower their available time for productive Deep Work.
5. Bad sprints have inadequate resources. Changing team size, lack of resources, or unplanned PTO can all put a strain on the team’s ability to tackle their goals and tasks.
Fortunately, our common issues have accessible solutions. Here are the top themes that emerged when reflecting on the most successful sprints.
What to do ✅
Now, let’s talk about good sprints
6 practices for effective engineering sprints
Of course, customer fire drills can derail even the best-planned sprints. For areas within your control, here’s how to set your team up for success.
1. Good sprints have goals. A good sprint has clear goals that are specific and communicated across the team. An excellent sprint takes time to measure against those goals once you cross the finish line.
2. Good sprints complete planned tasks. Before a sprint kicks off, there is usually a set plan for what needs to be accomplished. We heard over and over that good sprints focus on accomplishing that planned work. While it’s hard to avoid the inevitable tasks that come mid-sprint, strong teams and managers know to prioritize the initial plans first.
3. Good sprints have swarming. We know that healthy productivity happens with minimal distractions and context switching. In order to support that, teams can “swarm” around one theme or focus area. Doing so helps to reduce the number of people working in different areas or problems, and (as the name suggests) creates a buzz of collaboration since groups are focused on the same thing.
4. Good sprints include demos. Ideally, team members should be able to demo something they worked on, like a new feature, spec, or answer to a problem they solved. Demos show the rest of the team what progress has been made and allows people to learn from each other. The extra recognition doesn’t hurt, either.
5. Good sprints lead to good work. We define high-quality work as having low bug counts and few, if any, surprises. It’s okay to finish a sprint knowing that a certain functionality isn’t working. It’s not okay to assume everything is working and find out that it breaks after it’s shipped.
6. Good sprints lead to progress. Good software engineers are always learning and evolving. So when we say “lead to progress,” we don’t mean that a new feature needs to be shipped. A good sprint could result in a failure, but if it pushed the team to learn something new and moved engineering work forward, that’s ultimately productive for your organization.
In part 2 of this series, we dive into what makes a good team.
This post was written by David Youssefnia, PhD, co-founder and Chief Strategy Officer at Uplevel.