We did that successfully. And I’m 100% sure that one of the big reasons was the method that we adopted – agile development with weekly iteration pace. Since that very project we used the agile methodology to other projects and it worked out fine as well. So what’s the benefits of 1-week model?
- 1-week iterations are ideal for project teams of less than 20 members. If the team of this size develops a new product, I would call this an optimal path to your product.
- Weekly iterations work great for both new product development and maintenance of the existent product.
- Works great for complex products.
- 1-week iteration is not mini-version of a two-week iteration. Its anatomy is quite different. Not going too deep I will just say that weekly iteration model actually means that the team commits to what they think they can do within the iteration and then run as fast as they can to achieve iteration objectives. BD chart and team velocity do not make a lot of sense here unlike in case of 2- or more-week iterations. This is in fact one of the reasons why I’m not calling our method “Scrum”. It does not totally “qualify” as scrum by definition.
- 1-week iteration model is very good in cases when the team encounters radical changes on their project. It can be dramatic change in scope or total repurposing of the product or just the new product, another technology stack, staff changes (new product owner, for instance).
|Alex makes a number of excellent points in his post. However, I think it’s interesting to note that we gravitated to the one-week iteration mostly by accident. Since we were all fairly new to the domain (search) we decided to start with one-week iterations in the exploratory phase so that we could gather and share knowledge more quickly. Quick exploration-quick feedback-quick adaptation. I always assumed we would go to a more typical two-week iteration once we started cutting real code.|
In fact, we became addicted to the rapid feedback that shorter iterations provide, and we learned to appreciate the extreme incrementalism required when building a large system in small increments. Once mastered, I don’t think we ever considered doubling the iteration length. After all, who wants to then wait twice as long so see real progress, get feedback from the product owner, and deliver new functionality.
This fast cadence served us quite well as we navigated the many twists and turns that we encountered as a startup finding our way in a new market.
Of course there is a tradeoff with iteration length – basically the overhead of planning versus the rate of learning – but if I had it all to do over again with this extremely agile team, I would pick one-week iterations on purpose because the rate of learning trumps all.