Iterate Quickly

That's what others recommend

Recently I've being reading 2 different texts, and they both mentioned how high-velocity iterations are important and better than high-quality iterations.

First one, is article by Jeff Atwood, where author writes about “Boyd’s Law of Iteration”. Article is quite interesting. It introduces us into the history behind the Boyd's law of iteration. Article as well emphasizes the law itself: speed of iteration beats quality of iteration.

Second one, is latest annual later by Jeff Bezos to shareholders. In section "High-Velocity Decision Making", author also emphasizes superiority of high-velocity decisions over high-quality decisions. Interesting that Jeff Bezos finds that 70% of useful information is usually enough to make a decision. Waiting for another 20% or 30% of data might take too much time, and might be not as much beneficial.

In both cases, authors notice that making quick decisions and iterating fast can only work well if there is enough information available originally. And feedback is used to correct the course continuously during quick iterations.

In book The 5 Elements of Effective Thinking, authors also emphasize the importance to start fast. In section dedicated to making mistakes, authors encourage to not be afraid to start with mistake (if you don't know where to start), but continuously iterate incorporating received feedback and new knowledge.

Iterate Quickly in Software Development

What does it mean to iterate quickly in software development. I'm going to throw a few ideas, even though they are quite obvious:

1. Plan smaller and deliverables for each milestone:
   
   • define list of milestones
   • know deliverables for each milestone
   • plan time to receive and incorporate received feedback
   • follow the feedback, not the original plan: course-correcting is the right way to go.
2. Start testing faster:
   
   • write unit tests
   • write functional and integration tests
   • use staging for deploying latest versions
3. Deliver features faster:
   
   • if can't deliver a complete feature, then deliver part of it
   • if can't deliver to all customers, then deliver to some only, like internal or beta users
4. Sprint should take less time:
   
   • 1 month sprint is too slow in most cases
   • don't forget to make sprint retrospectives
5. Collect feedback from users continuously.