Iterations versus Continuous Flow
Last week I wrote a post on Iterative and Incremental development. In that post I pointed out that you can do iterative and incremental development without having time-boxed iterations. Mike Cottmeyer asked in a comment to clarify when time-boxed iterations made the most sense and when continuous flow made the most sense. This post answers that question.
When Time-boxed Iterations Make the Most Sense
Time-boxed iterations serve several purposes that are not well served in continuous flow. They create an opportunity for the team to stop and get feedback from the customer on their product. They can help with chunking up work to support the planning process and validation of the design of the solution. There are times when this is really important.
So, time-boxed iterations work best:
1. When there is a lot of opportunity for feedback on current deliverables to significantly update subsequent work
2. When the planning horizon is stable enough that a subset of the backlog can be prioritized for at least the duration of the iteration
3. When the backlog items can fit in the iteration time-box
4. When dependent resources (for example, planning and testing) can not be available to support continuous flow
For example, time-boxed iterations work best at the outset with a new product, new technology, or substantially new set of features.
When Continuous Flow Makes the Most Sense
Continuous flow has some advantages over time-boxed iterations. Overtime, the level of resources available to do work is higher and the backlog is much more flexible and adaptive to variation in the arrival of work. For example, once the product architecture is stable and well defined and work is arriving in bursts with various levels of urgency.
So, continuous flow works best:
1. When the work is arriving continuously
2. When the planning window can be (or must be) very small
3. When the outcome is pretty clear and feedback is not as likely to impact subsequent work
4. When there are multiple work streams operating at different cadences
For example, continuous flow when working on defects and small enhancements in a stable product or working with technical support issues.
Non-relevant factors
Effective planning. Data can be gathered from both iterations (velocity) and continuous flow (lead time) to determine when a product can be delivered and to establish visibility into the current status of the project.
Retrospectives. Iterations create a natural break for retrospectives. There is no reason why retrospectives must be tied to iteration releases. Continuous flow teams can have retrospectives on either an event driven or calendar driven basis.
Motivation to get to done. Iterations create pressure to complete work in a specific time-box. Continuous flow creates pressure to met lead-time commitments (policies).
How they can work together
We are making a standard practice of combining Kanban at the strategic planning level to support continuous flow of strategic initiatives across the organization and Scrum (or Kanban) at the development team level. It doesn’t make sense to us to create time-boxed deliverables at the strategy execution deliverable level. We generate plenty of pressure to move forward from the time commitments on the tasks on the Kanban board. At the development level – when there is a lot of opportunity for feedback to update subsequent work – we (may) use iterations to keep the team focused. For defects and minor enhancements we continue to use a continuous flow model – maybe within the same team.
Iterations versus Continuous Flow?
I believe this is a hammer versus saw discussion. Each approach is suited to fit different scheduling and feedback needs. In many cases, time-boxed iterations make a lot of sense but would result in a less than optimized approach then in other cases. I believe that early on in a product (when there is a lot to be learned and a lot of risk to manage) iterations probably make the most sense. At some point, when the product has switched primarily to support, continuous flow makes the most sense. I hope this answers Mike’s question from my previous post.
Tags: Agile, Kanban, Project Management, Software Development
I would like to add one additional criteria: please consider the socio references for work. Certain cultural/regional differences about how work is approached may affect your choice.
Interesting. I believe this is true. I guess on organizational culture aspect would be if you are in an organization already doing iterations – then it would be difficult to introduction continuous flow.
What other cultural/regional differences about how work is approached should be considered?
Interesting post!
I asked few question from Dennis in twitter already but then I thought sharing and elaborating them here.
I am a co-founder & CTO in a startup that practices continuous flow in product development, though we used to practice time-boxed iterations. If you care to read how we changed our process just take a look at: http://huitale.blogspot.com/2009/10/huitale-way-is-it-scrum-or-is-it-kanban.html
And our current way with total value stream: http://huitale.blogspot.com/2010/03/huitale-way-our-value-stream-map.html
In twitter I challenged the point “Continuous flow makes most sense – When the outcome is pretty clear and feedback is not as likely to impact subsequent work”. For us it has been the opposite. It made sense to drop time-boxes to enhance the feedback cycle (one piece flow, faster cycle time, faster feedback from the market).
Eric Ries has defined A startup as “a human institution designed to deliver a product or service in conditions of extreme uncertainty” so it is has nothing to do with the size of the company, the sector of the economy or the industry the business is involved in. For me it means two things in this context: 1) there is no stable product 2) feedback from your internal iterations is less valuable than iterations that you do together with the customer (customer development is the thing that we talk in lean startups). Therefore getting stuff our faster (continuous flow instead waiting for the time-box to end) gets you the feedback faster.
Under these circumstances we practice continuous flow and it seems that our insights seem to contradict the claim that “time-boxed iterations work best at the outset with a new product, new technology, or substantially new set of features.”. If I would have written similar blog entry, I would have told the opposite and that made me wondering is it just me
)
I also happen to consult companies with agile & lean and usually help them start with iterative time-boxes. Why? Because time-box gives a boundary in their chaotic environment. Starting with continuous flow would be too hard as they do not know their WIP nor their value stream(s) and figuring out those will take some time.
So my conclusion would be:
Iterative time-boxed approach makes most sense when you have chaos and you need to establish a boundary to get something done. Otherwise prefer continuous flow.
Thoughts?
We would like to be optimistic and believe that 2. planning horizons are stable and 3. we can estimate accurately to fit backlog items into a sprint.
It is easy to be overly optimistic or think that we should be able to do these well. In fact, it leads down a potentially destructive path of “We have to get better at estimating.”
Marko,
I think you make an excellent point. You get faster feedback with continuous flow. I also agree with your conclusion – although I believe it is situation specific. I don’t think we are that far off.
I support iterations early on – as you said, when you have chaos and you need to establish a boundary to get something done. At these boundaries (time-boxed), I want the entire team and the customer to stop and consider the product (customer feedback, are the early assumptions being validated), their processes (how they are testing, how they do branching, how the design is holding up, what is unclear about the architecture, where they might need to re-factor dramatically, where they are building technical debt), and the way they work together (how they are forming, how well the feedback cycles are working, where are their constraints or conflicts in the team) early on.
I agree that iterations you do together with the customer are critical. But very early on, I want to do a couple internal iterations. We need to answer architecture, process, and team questions like: How do I set up the Continuous Integration environment; How do we create test data; If we are using Fitnesse or Selinium how are we integrating that into our process to provide rapid feedback and get better requirements; Which UI Grid Control is more performant; How are we doing pairing or code reviews; How can we work with the DBA’s and PMO to keep them happy while moving forward?
Every team is different. For me, the outcome is pretty clear and feedback is not as likely to impact subsequent work doesn’t mean we aren’t learning and improving or have stopped adding new value to the product. It means we have primarily settled on our architecture – we have basically settled on our processes for scheduling and feedback – we know who the customer is and basically what problem we are trying to solve – and our team has formed into a relatively cohesive unit.
In some cases, and it sounds like in your case, this state is reached very early on. Typically this indicates mature individuals on the team and a strong vision of how to do the work and where the product is heading. In other cases, it takes more time for a team to get to the point where they can switch to continuous flow and continue to learn.
I am going to put some thought into this and write a subsequent post clarifying these thoughts.
Thanks for the insight.
Dennis
Dean,
You are correct. Trying to get better at estimating can be destructive.It is the breaking of trust with the business from making promises you can’t keep that leads to this destructive path.
The key in sprint planning is to be able to differentiate between what you know you can commit to and what you are doing in order to generate feedback. “We will finish these two stories and get a spike done on this third one so we can accurately commit to it” is an okay place to be. Learning that the third story is easy delivering it in the sprint is better than finding out it is hard and saying “we that we harder than we thought”.
Whether you are doing iterations or continuous-flow you still need to have these discussions with the business.
Dennis