Setting up For Success: Turning around a Struggling Team

Lee Dobryden
FordLabs
Published in
3 min readFeb 6, 2019

Being part of a struggling team is one of the hardest situations you can experience at work. When you’re in that situation it can feel like there’s nothing that can be done to make it better. Days are frustrating and team morale is low. Struggling teams also get a lot of attention from management, which can pile on the stress level. Getting your team back on track, however, doesn’t need to be hard. The biggest difference between a high performing team and one that is struggling is what they do to set themselves up for success from the start.

Pair Programming — one way to help ensure success

At my previous job I joined a team that had not established a pattern of success and was getting a lot of pressure to improve. The team was struggling to complete sprints and sometimes didn’t have a single story done when it came time for sprint review. This was a team of great engineers and one of the strongest product owners I have worked with. The team had all the pieces in place to be great, but hadn’t been doing themselves any favors to complete sprints. It didn’t take much to turn the team from one that struggled completing work on time for sprint review to one that delivered high quality work week in and week out. The team had great potential, but hadn’t set themselves up for success to get there.

When I joined the team, the first change we made was to limit work in progress. Developers constantly started a new story while another was blocked, which created a scramble to finish everything on the last day of the sprint. We implemented a rule where team members could only have one story in progress at a time. This meant that from the time you started work on the story it was the only thing you could work on until it was in production. This idea was met with skepticism, as it commonly is, but it was the key change needed to turn the team around. As developers became blocked they worked to solve the issues that were preventing them from getting their work to production. If stories were taking too long it was noticed during stand up, and the team worked together to move it along.

A key change we made to help stories get completed more easily was to make them smaller. We got creative breaking stories down, sometimes stretching what one might consider valuable. This particular company had clients that were accustomed to making changes to their account over the phone. The new product’s goal was to create a self-service platform to attract more customers and reduce cost. We realized that a REST API was valuable, and that we could leverage our API to handle client requests. This helped us limit possible scenarios, thus narrowing scope and making stories completable in a few days. Later we added the self-service UI, once we gained a better understanding of customer needs. As the product matured we had more reusable components, making it easier to combine backend and frontend work into a single story.

Once we prioritized finishing work over starting it we were able to successfully complete a sprint. This small win led to more and more wins and quickly we built a habit of delivering consistently. With this habit established more good habits followed. We took time to set up the right environments for testing, automated deployments, and became good at making well-sized stories. None of those improvements would have been possible if we hadn’t done ourselves that first favor of limiting WIP to set ourselves up for success.

If your team is struggling, remember — it’s not cheating to do yourself favors like cutting scope or taking on less. Chefs never start cooking without their Mise en place, golfers take advantage of the tee box — help yourself out too! Each team is unique and will work differently, but all teams have the same goal of getting their work out in the world and helping people. If your team is stuck, narrow scope, limit risks, and do everything you can to ensure you’ll finish every sprint. As The Agile Manifesto says “Deliver working software frequently”. Learn to do that. The rest will follow.

--

--