In considering a leaner approach to software development, many people in the agile community are starting to turn towards an iteration-less approach. Wayne Allen talks of trialling No More Iterations, while Amit Rathore talks about an iteration-less agile process. Heck, I’ve even given it a go with a couple of my projects. On the other hand, there’s a whole movement in Italy devoted to the Pomodoro (Tomato) Technique that focuses on time-boxed activities.
So who’s correct?
The short answer: They both are.
Photo of a “time box” from Great Beyond’s Flickr stream under the Creative Commons Licence
The long answer: When you compare people not working in an iterative fashion (i.e. one phase of analysis, one phase of development, etc), to those agilists now turning away from iterations, there’s a noticeable difference, and is what I will call, discipline.
Those arbitrary time boxed units that we call an “iteration” creates cadence for teams. Cadence in turn creates rhythm, where teams can focus better on developing the healthy habits associated with agile software development. Much like the way that beginning martial artists repeat katas, it helps the Novice, Advanced Beginner and the Competent (Dreyfus Model) understand each practice individually and develop the discipline to make them effective. They don’t need to worry about which practice combines best with other practices, and yet, still see some benefit. It helps the team synchronise, predict and potentially even enforce when activities happen, giving people the stability they need when they are learning. It forces people to make important decisions that, without the associated discipline, end up deferred.
In absence of iterations, you need a guide to achieve a similar effect to encourage people to use the practices in an appropriate order. I argue that those people who are Proficient or Expert (Dreyfus Model) don’t need the iterations because they understand when to use what practice and the value it brings. They move towards what looks like an “iteration-less” approach because they are instinctively doing things iteratively without the arbitrary time box. They have enough discipline to ensure all the activities happen at the right time without causing disruption. Unfortunately, in my experience, many never make this jump to being Proficient or Expert.
What to do about it?
Iterations are useful, with that usefulness limited to a certain context. The learning level of the people involved heavily influences this. Respect the needs of the people you work with, and understand that jumping into “no iterations” requires a level of discipline you won’t achieve without people reaching these later levels of mastery.
I Definitely Agree with your post Pat,
Even long iterations (or Scrum sprints) are dangerous: iterations are very effective on keeping the focus of the team on what needs to be done in a time slice in order to call it “successfull”, in order to feel the smeels and what’s not going so well.
On the other hand, too many times I’ve seen iterations that are cutting the rhytm of the team, as also the pomodoro tecnicque does too on a pair level.
I remember the good practice (we had) of putting two story cards showing traget points for the week/points done as information radiator on the team wall, does this imply that the team is using iterations? I don’t think so. Does the team gain any benefits? IMHO A lot.
I like your post, but I think I disagree with the conclusion.
I personally have found that an ‘iteration-less’ approach is actually more fluid and intuitive for novices. Instead of having to understand timings, set iteration lengths and then regularly try to predict what will be done in an iteration, ‘iteration-less’ relies on simpler concepts of dependency (pull) to control when tasks should be performed.
My most recent project was almost totally staffed with people new to agile development and my experience there was that they very quickly picked up on the process with much less questioning or confusion that I’ve got before when trying to do a more traditional iterative approach. Iterations require explanation to really communicate the process. Pull+flow requires doing and appears easier to learn intuitively.
I also disagree with your conclusion!
My experience is also that an agile iteration-less approach can feel more natural to new team. The cadences required to instil discipline are different however. Rather than there being a single ‘sprint’ cadence, which couples planning, estimation, review, release, retrospection etc together, each of these activities can have its own cadence.
Hi Chris and Karl,
Thanks for posting a comment. I appreciate your insight into this. I can see how your experiences have worked for you with introducing agile to teams. It also sounds like part of your teams’ success is the structure you create and that you are helping guide them to ensure they reap the appropriate benefits from the practice. I mention this above:
I know of a few teams who have “iteration-less” approaches and forget to do, what I consider essential practices, like retrospection and constant improvement because they lack this experienced guide, or a timebox to remind them about.
Also, I wonder how intuitive this process is (it sounds like it is to both of you who I might consider Proficient and Expert) when much of the industry are not doing iterations, and lack the discipline to execute the practices appropriately. As you mention above, all the activities can have their own cadences, yet when I look at many organisations I go to, they have not yet developed the discipline to recognise them and execute upon them.
I actually still think there is a place of iterations – I should have made that more clear. Iterations do give a timebox for more repetitive, non-demand driven practices like showcases and retrospectives*. These are best done on a regular basis to give the opportunity to reflect and improve, and are easily forgotten if there isn’t a scheduled rhythm to their occurrence.
When it comes to scheduling stories, however, I don’t think the iteration ‘planning’ is necessary and appears less intuitive then having a pull+flow approach to moving work through the team. There is an argument, as toni has suggested, that having an iteration plan allows the team to focus on “success”. I think this is good, but also dangerous – as it can often result in overconfidence, which leads to procrastination (such as leaving work till the end) and risky behaviour (such as breaking of functionality early in the iteration, because there’s time to fix it). It is also dangerous because you either have to plan for less stories than the team should be capable of, resulting in under-utilised capacity during the iteration (or pulling more stories into the iteration), or plan for more stories than they are capable of, which will kill the sense of “success”.
Instead, I prefer to focus on “throughput” as the measure of success for the team. If we can achieve and maintain (or improve) the throughput, over any arbitrary period, then we are working well. Yes, you could even use iteration boundaries at the point to look at, and reflect upon, the team throughput – at which point it is called velocity. That seems like a quite reasonable point, as long as the iteration is small.
Once you look at it this way you realise that the regular rhythm does not have to be consistent for every activity (although it is easier if it is). For example, one might do retrospectives every week, to allow the team plenty of opportunity to reflect and improve, but do showcases every two weeks due to the availability of the business. It is quite possible (and reasonable) to have more flexibility in this scheduling. The point is just that these activities must be regular to achieve the cadence Pat is looking for.
Conclusion – regular scheduling for non-demand driven practices is a good thing, as it creates a rhythm (or cadence) for the team. And for scheduling of work, rely on pull+flow which I find is often more intuitive.
cheers,
chris
* I actually believe that deployment should also be one of these regular practices. Deploy regularly and often, regardless of functional change. But this is the topic for another blog (that I might write soon if I stop writing comments instead 🙂 ).
I find myself both agreeing and disagreeing with you Pat, and so with some of the comments as well.
I’ve been using timebox techniques since before I knew that’s what they were called (mid 1980s at latest). My use of them has changed a bit over the years.
Generally speaking if there is any body new on the team, novice or expert, the whole team goes back to timebox-like iterations until we are all communicating well — that is, until our everyday chit-chat within the team makes the ‘official’ meetings of the timebox a bit of a waste of time.
Once the team is experienced with each other, it’s back to a continuous process. I’ve found that the normal everyday chatter among the team members is sufficient to communicate what we need, possibly with an occasional “reality-check”
I guess we move between practices as appropriate.
Wonderful comments everyone. Thanks for posting them. As I hope it comes across, I’m not saying that everyone has to use iterations – rather, trying to understand in what context iterations are useful. It’s important we push the boundaries to understand when we can get away with iterations whilst understanding what iterations bring for us.
Bob, I’d be interested to see what things you agree or disagree about. I can see how iterations might help new team members synchronise with the team and head for a more continuous process. It sounds like you move between practices appropriately. I have also seen other teams who never do.
Chris, there’s quite a lot in your post and whilst I agree with a lot of what you say, I also find the conclusion as dangerous for all teams. Pull and flow might be more intuitive for some teams (with a guide in place to help establish them), iterations (in the absence of a guide) might work better for others. As I’ve found coaching many different teams, it always depends.