Powerful ways to build amazing teams (3 of 5)

Slow is smooth, and smooth is fast.

–US Navy SEALs

Your team is trying to go too fast. There, I said it. Deal with it. OK, maybe I’m stereotyping your team as being like almost every other team I’ve encountered over 35+ years in high tech companies. In other words, the odds are on my side that I’m right. Teams try to go too fast. Recently I addressed this topic in an #AgileDailyDose video:

The faster teams try to go, the slower they actually go because they make too many errors along the way. Going too fast is a surefire way to get in trouble on a project of any size. You go more quickly by slowing down. I’ve heard the quote at the top of this article, “Slow is smooth, and smooth is fast,” in a lot of different contexts. I’ve also heard “Slow down to speed up,” which I also like.

You might rightly ask, “OK, smartypants, how do we do slow down without causing issues?” That’s a great question, so let me give you three things to try:

1. Be realistic about your recent results. Is your team completing work with high quality, or does the team regularly have to fix bugs? If you are in this situation, then it is time to have a challenging conversation with your team’s stakeholders about the real results. Proposing slowing down to cut down on bug fixes will usually get a positive response when approached correctly. So what is the correct approach? Make it be a win-win. Help the stakeholders understand how bug fixing is causing a slowdown. I usually like to say something like, “Over the past four iterations, we’ve spent 30% of our time fixing bugs that were caused by going too fast in prior iterations.” Once they understand the problem, you can suggest an experiment of forecasting 20% less work in an iteration so you can determine if slowing down actually ends up making the team go faster.
2. Determine how much time the team is spending on things that aren’t in their backlog. I call this time that “leaks,” and it can be significant. If you are doing a Daily Scrum or something equivalent, then before closing the event, you might want to ask the question, “Did anyone work on anything that isn’t in our Sprint Backlog?” The question will immediately expose any hidden work. Examine the hidden work to see if it is important enough to be done before the sprint backlog work. If it is, then don’t just do it, have a team conversation about how it will impact the sprint.
3. Improve the technical practices the team is using. This one is primarily for software development teams. There are core technical practices that were created to help agile teams deliver high quality within iterations. Rob Myers has an excellent (and long!) article about it here. Invest in helping your team get better technically, which will show in improved effectiveness.

Going too fast is a hard problem to solve. Most teams are backed into a corner when a release date and scope are set without any input from the team(s) doing the work. I believe people are hired to work as professionals in a professional manner. To me, that means making hard decisions about cutting scope to meet quality requirements rather than “Ship it broken, we’ll fix it in production!”

We all know going too fast will cause quality issues. What we don’t realize is quality builds speed. We get it done right the first time. which is faster than getting it wrong then fixing it. I’d rather have one good release than have a bad release followed by a fix. I think most customers would prefer that as well, even if it means waiting a bit longer to get the good release the first time!

I cover this kind of information in ALL of my courses. Check out our upcoming courses if you are interested in exploring this topic and many more!

Read part 2 of this series here, and part 4 here.