The Value of Speed and Iteration

Problem

When I’m asked what my number one principle is in the world of engineering and product development, the answer is usually speed of iteration.

I really don’t think that this opinion is revolutionary or even original, plenty of engineering leaders and engineers will agree. I think one of the really key things that people often miss, and engineers are among these people, is the value of many shorter iterations. The more iterations that your team is able to generate, the more chances you have in your pipeline to correct your course when you sail astray.

In order to have a lot of iterations, you need to have speed. The faster you work, the more chances you have to iterate. You only have so much money and so much time to produce what you wish to share with the world.

Actions taken

The way I often explain it to people: imagine that you have a budget of four weeks to build something. If you spend four weeks building the first version and then release it, you’ve already used all of your chips. You’re done.

If, say, instead, you spend only one week on your first version and then release it, that first round of user feedback comes all that much sooner. Now, you have three weeks to iron out any problems with the product. This will usually result in a much more robust final product.

The first natural objection to this school of thought: if you’re constantly moving so quickly, how will you be able to manage and maintain a high bar for quality? If you go too fast, don’t you ship crappy code and a crappy product? This is actually a false dichotomy. Speed and quality go together. Refactoring code early and often results in better code than trying to design everything upfront. The same is true for product development.

One way to promote fast iteration is to measure cycle time. Cycle time is the time between when somebody starts working on a code change to the time that it is merged to master. The bigger the code change is, the longer that this cycle time will be.

On a typical agile team, if not especially concerned with speed, the average cycle time may be seven or eight days, depending on what type of product is being built. A cycle time this long means that you’re definitely not delivering value to the user on a weekly basis. I have a goal for my team’s cycle time to be around two to three days.

Think about the change you are making: what value would it have if you released it today, as opposed to in a month? Could you split your change into smaller pieces so that you could deliver some value today already? A user story in progress brings no value to the customer. Releasing even a small portion of it sooner will bring value to the user and to you in terms of this extremely important first round of user feedback.

Lessons learned

• One thing that I do with my teams: I force them to come up with a weekly goal for themselves. They have to find a way to relate the work that they’re doing to customer value. Essentially, they have to find a way to deliver this customer value every single week. It’s a good forcing function that ends up encouraging these shorter, more frequent iterations.
• The faster you are moving forward, the more chances that you have to catch any bugs in your product. If you just release a bunch of stuff together, you won’t even know where the bug is coming from. By that point, you’ve already run out of time to fix everything for the users.
• Splitting the work into very small chunks and making sure we are clear on how each piece of work delivers value to customers are my two strategies when it comes to helping the engineers that I work with.
• It’s not enough to just put your product out there and to wait. You have to actively be managing it as your users respond to it. I think that this is something that we have not quite perfected yet as an industry. On your Trello board (or wherever you are managing your team’s work), add a column reminding them to look back at what they released.