Some four years ago we started a product development effort for a company named Skoop Heavy Industries. Very complex product I have to say, a search system that would index 1-1.5 billion web pages and provide user with a unique people search capabilities. Probably the biggest challenge was to implement the system fast out of the concept and tiny little prototype giving you general idea of what it is, but no more than that…

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).
I think it was great luck that the person who introduced this methodology to us was simultaneously the CEO of Skoop HI. His name is Dean Leffingwell, serial entrepreneur, formerly senior executive at Rational Software, and these days – independent agile development consultant and software methodology thought leader. Dean’s major focus now is scaling agile method across huge enterprises which he helps companies to succeed with. The method is reflected in his book: “Scaling Software Agility: Best Practices for Large Enterprises” and lot’s of new interesting ideas and facts in his blog: I don’t think that this post would really be complete without Dean’s opinion on the subject:

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.
Alex Yakima
Paul is a software architect for Luminis Technologies and the author of “Building Modular Cloud Apps With OSGi”. He believes that modularity and the cloud are the two main challenges we have to deal with to bring technology to the next level, and is working on making this possible for mainstream software development. Today he is working on educational software focussed on personalised learning for high school students in the Netherlands. Paul is an active contributor on open source projects such as Amdatu, Apache ACE and Bndtools.