Has Agile Peaked?

Iterations Are Short

Similar to last year, we found that the majority of respondents indicated that their iterations were between one and four weeks in length (see Table 1). It was interesting to see that the number of teams that aren't doing iterations appears to have increased, perhaps an indication that people are moving towards lean methods such as Kanban (more on Kanban in a future column).

My experience is that shorter is better than longer when it comes to iteration length because shorter iterations help to squeeze out low-value bureaucratic activities. For example, you can't tolerate a three-week review process when your iterations are only two weeks in length. Teams that are new to Agile often have iterations that are longer than four weeks in length, usually because they're still in the process of moving away from a serial/waterfall mindset and are struggling with the idea of producing working software in short time periods. They're often convinced that the requirements that they're trying to implement are so big that they require iterations of six weeks, eight weeks, or even longer. Having worked with project teams in numerous companies around the world, usually developing very complex software, I have never run into a large requirement that I couldn't disaggregate into much smaller ones. My observation is that teams always seem to find ways to break down their "three month requirements" into tasks that fit into eight-hour workdays. Granted, when team size increases, or when the team is distributed, it puts pressures on you to increase iteration length. For example, the Eclipse development team, several hundred people around the globe developing a complex system, has six-week long iterations.

Small requirements are easier to estimate, implement, and validate than larger ones, but it's easy to lose track of the big picture if you're not careful. Although many agile teams create user stories, very small features that provide value to a stakeholder, they're also writing "epics" that are collections of related user stories. Some teams are writing lean/light use cases describing how one or more stakeholders will use the system. The most advanced teams are focusing on business scenarios, or "green threads," which involve usage of multiple systems to provide business value to stakeholders. These cross-system scenarios explore the true business processes of your stakeholders (few people sit down all day long and solely work with a single system), and thereby enable you to see the real "big picture" and hopefully avoid building yet another silo system.