One of the principles of agile development is increasing feedback by decreasing cycle times, continuously iterating on products. Over the years we have seen the progression from infrequent integration, to continuous integration, to continuous delivery (and beyond!). As we see teams trying to improve their development practices, they are often encouraged to take measures to reduce the length of the cycles they work in, from releasing every 6 months, to releasing once a month, or from once a month to once a week. Rather than working on big stories or features, we try to break them down into small features. This goes all the way from product road-maps to red-green-refactor TDD loops. Reducing cycle time is generally accepted to be a good idea and something to work towards, but why are we doing it?

For a lot of teams, the length of the cycle is an easy thing to measure and to feel good about reducing: “we went from releasing once a month, to once a week!”. But why is it better? Two reasons: 1) limiting work in progress, 2) access to feedback.

Reducing work in progress is one of the themes stressed by those following kanban methods, but as well as reducing the number of work items that we are processing concurrently, we also want to reduce their size. This has the simple benefit that they are easier for our limited human brains to think about, and easier to complete. At every point that we have something that is “complete”, we get the opportunity go gather feedback, either from team members, product managers, or direct from our users.

Gathering feedback is important because it tells us whether or not what we have done is good. However, the most important aspect is that we should act on this feedback. Many teams that I see are following an “agile method”, and are working in weekly, or two-weekly, or monthly cycles. They’re developing features and they may or may not be releasing them to live on a regular basis. But they aren’t completing the loop - they are planning and working in smaller chunks, so they have less to keep in their minds at once, but they aren’t taking full advantage of completing each section to provide new information feeding in to their plans. They are typically following a pre-formed plan to a pre-defined goal, chipping away at it incrementally, rather than learning and changing plans at every cycle. Agility is all about having the ability to change direction easily. If you aren’t going to try to change direction you lose a lot of the benefit.

Eric Ries’ work on the Lean Startup focusses on obtaining feedback and validated learning over building product increments. There are still cycles, and reducing their length is still desirable, but the main outcome from each cycle is the incorporation of the feedback, which informs what we do in the next. If we can gain the learning without building any software at all, this is in a sense ideal.

I’ll be speaking on this topic at the GOTO Berlin conference in October, so look out for that session if you’d like to hear more.