Optimize iteration length for feedback
If there is one theme that is weaved through all of Agile’s principles and practices, it is feedback. TDD. Pair programming. Continuous delivery. Stories. Estimation. Reviews. Retrospectives. On-site customers. Feedback comes up against and again. Feedback from code, the team, and users.
As I mentioned in my previous post, I am a big fan of short (one week) iterations. Feedback is why. If your team works in three-week sprints, and mine in one-week sprints, we have three times the feedback. I have three times the opportunities to learn and improve. While you debate whether to try something new in a future sprint, we try it out immediately and evaluate whether it’s working every week, until we accept or reject it. We become three times as good at estimation. We know in a third of the time you do that a solution to a problem works.
Perhaps in some situations one-week is too long. You could try two-day iterations early on with a new project and new team. Or perhaps, on a legacy project, even two weeks is too short and you don’t get enough work done to get good feedback. You can get faster feedback going to three week sprints, rather than having to wait four weeks (two two-week sprints). The point is to optimize for feedback. This means you should prefer shorter sprints, but there can be exceptions.
The benefit of feedback cannot be overemphasized. In a previous post, I said no single aspect of the Toyota Production System is more important than the others. That’s not entirely true. “Continuous Improvement” can bootstrap the other TPS components. You improve through getting feedback. It follows that you should do anything you can to get better and faster feedback.
Yep, well put.
One peeve of mine is when retros are flaccid. If your retro consists of only good things and/or complaints of “other teams need to do better to not cause problems for us”, then something is plain wrong. It’s exactly this time you need to be collecting and verifying feedback. Failure here stops the wheel of continous improvement, so it’s on you to be critical and on the ball! Challenge yourself to find areas to optimize.
Sometimes I think retros are the most important part to stay agile, though of course it’s not as simple as that :)
Retros may be the most important structural component of staying Agile. Without the ability to retrospect well, you cannot get feedback, and (as you identify) you cannot improve. Of course you still need to be able to *act* on that feedback, but you need good retros to get it.