Iteration Patterns

Implementing iterations into any group and team within an organization is like choosing a shoe. Choose the right shoe, and I am thankfully forgetful of their existence while focusing on something else. Choose the wrong shoe, and its all I can think about to the exclusion of most, if not all else. Based upon my experience, I have developed explicit likes and dislikes contextual to situation and context (summer, fall, winter, spring, wet, dry).

  • Hike: rigid sole, waffle tread, water-proof, breathable
  • Run: breathable, high shock-absorption, comfortable lacing
  • Golf: casual look, breathable, mid-tier costing
  • BBall: high cushion, ankle support, breathable
  • Hunt: water(resistant,proof) breathable, calf-coverage
  • Diving: fits inside fin toe-box comfortably, easy to put on/remove wet

So how does one choose an iteration pattern? Just like shoes, try them on long enough to develop an opinion. At some point though, everyone is forced to make a decision -- do I purchase these shoes, do I keep looking, or do I simply walk away on the speculation that I don't really need any? Making a decision is hard. Sticking to the decision is hard. Some people will leave the store without shoes. Some will leave with shoes they will wear once or twice. Some will actually use their shoes past their responsible usefulness. And some will wear them for the right situation and length of time, recognizing when it is time for a change. Denial of reality is an oft-common problem. Seems to apply to shoes and iteration patterns alike.

Of the iteration patterns below, what makes sense for one group may not make sense for another. Similarly, what makes sense for one industry/product/team type may not make sense for another. First we must choose, then we must learn and change.

[30m],[60m]or[24h] Pattern
Descriptor: Useful for delivering very small increments, very frequently. Presupposes a mature, in some cases a very mature, automated continuous integration, continuous test, continuous inspection and deployment framework. To increase to this responsiveness through purely manual organic efforts alone, including test/build/bundle/deploy activities, will be very difficult and stressful -- though not impossible. More moving parts at higher velocities demands more machine time and less dependence on eyeballs. Units of work must be small, benefits are gained by high automation associatively.

5d Pattern
Descriptor: Useful for FIFO or FIFO-like activity bursts such as Infrastructure, System Administration and Support groups where work units are small and responsiveness must be near-immediate. Heavy reliance on automated processes and tough on organic dependencies. Similar attributes to the "[30m],[60m]or[24h] Pattern". Both of these patterns run the risk of confusing 'speed' with 'value'. They are not synonyms.

10d Pattern
Descriptor: Useful for "just short-enough, just long-enough" cycle-times for teams such as Development and Infosec. Especially good for petri dish experiments where teams need to try out an idea without investing too much time. A good balance of organic and automated solutions with a tendency towards more automation than organic.

30d Pattern
Descriptor: Useful for situations where a thirty day delivery is quick enough, work units are large enough, and market demand allows both. Also a good pattern for petri dish-like experiments where teams need to try out an idea without investing too much time. This is considered to be a classic Scrum pattern per Schwaber materials. Thirty days is horribly quick if you're previously used to longer product to market windows. Thirty days is amazingly long for those who finally get used to thirty days windows. Especially for business and customer constituents, remember what you win them with is what you win them to.

221 Pattern, [10d].[10d].[5d]
Descriptor: This is basically two 10-day iterations with a one week hardening iteration at the end prior to production delivery. The latter one week iteration could also be used as an incubation week where innovation is invited, fostered and amplified. If you work on the premise that at the end of every 10d iteration a tested, demo'able, usable software solution should be production deliverable, this additional 5d window at the end may be used in order to gain more confidence on performance testing, customer proxy testing, etc. This additional week may be used as a breather for technologists in order to clean up, optimize, scale up, re-organize, or otherwise modify their work and delivery environments or products and services. When you are constantly pumping out new tests and associative code, it gets fatiguing. Building a mental break into the scheduled to foster optimization and innovation provides higher dividends than running teams into the ground.

2211 Pattern, [10d].[10d].[5d].[5d]
Descriptor: Two 10-day iterations with a one hardening week and an innovation week thereafter. This pattern is really just a variation on an aforementioned 221 theme. Deliver working, tested, demo'able solutions at the end of each 10d iteration, take one week to harden it up and deliver it to production, and then have a one week innovation period thereafter. Then, repeat. A benefit of this pattern over the 221 is separating out the hardening effort from the innovation pattern. Having both hardening and innovation in the same wee may be tough for some teams dependent upon the maturity of teams and cultures.

There are more patterns out there.

Patterns are patterns. Relevance is relative. Financial geeks argue that if they can't measure it, then they can't manage it. What they are really talking about is having base patterns so that they can recognize anti-patterns and deviation. Likewise with iteration patterns, the point is not to box a team into something. The point is to listen, understand and craft a behavior pattern that matches the need and treat it as a pulse. When the pulse is erratic, something is unhealthy and requires attention. When the pulse is consistent, it enables attention to be diverted to something else. Knowing when to change is an art. Sticking to a change is choice and discipline.

Important and in my opinion overlooked is the use of pairing (+switching), planning, retrospective, demos and stand-ups which needs to be dialed up or down in ceremony contextual to the pattern, culture, maturity/experience of team-mates and what makes sense 'this' iteration. Then evolve.

Iteration patterns are like shoes -- I need what I need until I need something else. However, I need to wear them for awhile in order to develop an experienced opinion. Of course, 'awhile' is relative, but proper time is pertinently relevant to decisioning.


  1. The other side to this equation is the customer acceptance of the pace. Dependent upon the app/service, customer base, impact of frequency of change, overall confidence in the provider and a whole host of other things, the pattern must take these into account as well.

  2. Context should drive solutioning. It is important to try something, learn from it and evolve. Customers, markets, priorities, etc. change through time. So what once worked should be in a constant state of evolution if and when it makes sense. What seems to be missing so often is the application of common sense.