The Need For Speed

I’m always badgering teams about moving faster.  Yet I continue to meet people and teams that not only move very slow, they don’t understand the relationship between speed and innovation, or speed and quality.  In fact, many people still think those goals are at odds.  I attribute this mainly to a deeply rooted Waterfall mindset.

Do you remember the old: “quality, time or scope – pick any two”?  A lot of people still think this way, even many people that consider themselves practitioners of modern methods.

I have written earlier about the most common reasons why teams move too slow.

The reason for this note is to explain just why speed is so important.

Many people just assume that the reason for speed is simply for time to market (they believe the market window is closing and they need to hurry to get something out there before other players come in and capture the customers).  In my experience, while sometimes that’s the case, it’s a lot less common than people think.

As you’ll see below, time to market isn’t even one of my top 10 reasons for need for speed.  That’s because I believe there are even bigger reasons why it’s critical to go fast, even if you are not threatened by competitors, or by a closing market window.

Here are the 10 key reasons why going fast (the need for speed) is so critically important:

1. Speed gets you more iterations and hence more learning

Successful innovation is a function of the number of “at bats” or approaches to a problem that are explored and tested.  We only have so much time, and management only has so much patience, so speed enables us to try out many more approaches in a given amount of time.

2. Speed keeps the team focused on the MVP

Most teams have a natural tendency to over-build, over-engineer, and overly complicate their products.  The sense of urgency that comes from speed keeps the team focused on the smallest viable product.

3. Speed gets you active support from leadership

This one is admittedly a little political, but it’s very real nonetheless.  Those teams that move and learn fast get the support of the company’s leadership.  They see the progress.  They feel the energy.  It is palpable.  On the other hand, teams that move slow frustrate leadership.

4. Speed keeps the team focused on their purpose

Teams tend to drift over time.  Distractions arise.  People move on.  It is easy for a team to lose sight of their purpose and achieving their vision.  Teams that move fast have the vision in their sights and push hard towards it.

5. Speed leads to happier customers

It’s not surprising that customers are happier when the product gets better faster.  In most categories, bugs are acceptable so long as they are found and fixed immediately – usually within hours or days.  Now you might think that a team that has to stop what it’s doing to fix an urgent customer issue would be unhappy.  And it’s true that if that’s all they are doing they probably are frustrated.  However, teams that jump on customer issues and are deeply committed to their customer’s success, generally have the highest morale.  They know their customers are grateful, they know their product is valuable, and they know what they are doing is genuinely important.

6. Speed leads to better quality products

This is counter-intuitive to many people, but the old model of developers having a coding phase where they worked on a bunch of things, and then eventually throwing the code over the wall to QA to test all those things, not only was very slow but it resulted in generally poor levels of quality.  Too many changes at once, too much risk of outage, too hard to detect what went wrong and QA always squeezed for time at the end.  Today we know the key to great quality is to start small, focus on working software, leverage test automation, get it working well, and then keep it working well.  We do this with continuous and incremental development, integration, test and delivery.

7. Speed lets us get something live to our early customers so that we can start collecting actual usage data

We can learn and validate quite a bit during product discovery with prototypes and user testing, but for many things we need to start getting some actual usage data.  This data lets us prove what works and what doesn’t, helps inform the product direction, and helps us improve quickly.

8. Speed leads to higher morale

We want our teams to be highly motivated.  Excited to come into work.  They should always be learning and improving.  They should feel good about what they produce.  Speed leads to success, and this success leads to a highly motivated team.  The virtuous cycle of all this is that highly motivated teams also lead to more speed.

9. Speed keeps the team always looking for new and better ways of creating products

The sense of urgency that comes from a focus on speed keeps the whole team always on the hunt for new and better ways of defining, designing, developing, testing and releasing products.  It’s needed, and it is top of mind for the team, so no surprise how many strong teams come up with better ways of doing their job.

10. The ability to learn fast and move fast is arguably one of the only sustainable differentiators

Finally, today it is very hard to come up with truly sustainable differentiators.  Sometimes we can, but mostly if you can build something, others can build it too.  What they aren’t as likely to replicate is your ability to move fast and learn fast.

As always, it is critical to keep reinforcing that speed does not mean working 15 hour days.   Speed is a function of the skills of the team, the techniques the team uses, and the culture of the organization, not how many hours people are at their computers.

Often when the team is motivated and the sense of urgency is high, members of the team will choose to work longer hours, but this is a result of being excited and motivated.  If you have to tell people to work longer and harder then you may win a battle or two, but you will very likely lose the war.

Several people contribute to this sense of urgency and motivation, including the engineering management, project management/ScrumMaster, and company leadership.  But most of the responsibility falls on the product owner.  See here for a list of specific techniques to evangelize and motivate.