Lean software development: An iteration-less agile process

A lean software process offers a lot of possibilities. In this post, I want to try and explain why I think iterations are superfluous in a good agile team environment.

Premises

I thought I’d present my reasoning as a set of statements that together build up the argument. I’ll try to address the following things – business analysis, estimation and tasking, ensuring communication, iterations, requirements prioritization, planning, showcasing and closure, taking breaks. There’s probably more, but these are the areas where most people ask questions about this approach.

So here goes!

Analysis

– Business conditions and requirements can change quickly.
– Analysis therefore, is only valid for as long as the relevant business requirement is valid.
– To ensure that the team takes the latest requirements and information into account, therefore, it makes sense to delay analysis to keep it as close to development as possible.
– In an ideal world, analysis could be done real-time. Or, as they say – just-in-time.

Tasking (work-breakdown)

– Tasking a user-story is valuable.
– Developers don’t really pay attention when other developers are tasking other stories. Especially in large meetings. They communicate and figure things out in other ways.
– Developers often don’t even remember how/why they tasked something a few days ago. Sometimes, things change enough to make their earlier tasking less valuable as well.
– It makes sense, therefore, to just have the pair that’s going to develop a card, task it.
– It is also more valuable, by the same reasoning, to try to minimize the delay between tasking and implementing.
– The ideal is right before implementation – in other words – in real-time, or as they say – just-in-time.

Communication

– Large meetings are inefficient.
– It is valuable to have developers immersed in the domain.
– They learn from each other, and from BAs and QAs during discussions. However, the value of this exchange is diminished when it occurs in large meetings.
– The best form of communication is organic – face to face, across the team-room, during work, a little now and a little later, as required.
– Domain related (and other type) information , therefore, is not distributed only during IPMs, nor is it the most desirable form of this exchange.
– The best way is to have domain people and developers co-locate and encourage conversations and daily interaction

Iterations

– The duration of an iteration is arbitrary.
– The only important factor is that it shouldn’t be too long. People have discovered that 1 to 4 weeks work well. Can we do better?
– Iterations are an artificial construct, and just like estimation, they don’t (and can’t) alter the amount of inherent work.
– Zero is the smallest natural number.

Prioritization

– Customers/product-owners are constantly learning new things that impact requirements.
– Prioritization of stories must, therefore, be an on-going activity. It has nothing to do with ongoing development iterations.
– Even a developed user-story (the partially-developed product) provides feedback into this changing understanding and priorities.
– It therefore makes sense to reduce the cycle-time of developing a story – to allow for maximum, and fastest feedback.
– Prioritizing stories can, and should, therefore run in parallel, at all times.

Closure

– Showing progress to stake-holders is important.
– A work-in-progress should be show-cased to them whenever significant features are implemented.
– This implies a non-deterministic schedule. Pre-planned showcase-schedules therefore are not optimal.

Breaks

– A hard-working team deserves to take breaks and have fun.
– This again should be on an on-demand schedule – especially after a burst of extra-hard-work or overtime.
– This also implies a non-deterministic schedule.
– This holds good for things like retrospectives as well.

Recap

– Prioritization is an on-going, parallel activity that runs throughout the duration of the project.
– Analysis ought to be done just-in-time.
– Estimation adds little direct value to implementation.
– Tasking ought to be done just-in-time.
– An iteration is an artificial construct, and shorter the better.
– Showcasing work is important, and taking breaks is important, and these are non-deterministic activities and shoe-horning them into a ‘regular’ schedule is sub-optimal.

Proposal

– Reduce iteration lengths to zero. Do away with the artificial construct altogether.
– Ensure business analysts work with product-owners and stake-holders to maintain a constantly prioritized list of user-stories.
– Ensure maximum effectiveness of the development team by allowing business analysis, and tasking, and development to occur in a just-in-time manner.
– Showcasing product, conducting retrospectives, and taking breaks should occur whenever needed!

Final pitch

Hopefully, I’ve been a little more coherent in my thinking here than I normally am during my… well, incoherent rants. Ultimately, I want to be able to remove all parts of a process that adds no value by itself. Any opposition to this proposal would have to be in terms of what value iterations provide, and that this process will be unable to.

Oh, and also – this is a work in progress 🙂

Extra credit

– Do away with re-estimation altogether.

Coming soon

– What requirements should be satisfied in order for a team to be successful at iteration-less agile?
– What impact does this have on a client-vendor relationship: project management, expectations-management, risk-management and so on?
– Does iteration-less agile make life difficult for development teams that like to have short-term targets? E.g.- ‘200 points this week’?
– Possible disadvantages of saying no to iterations (everyone else is doing it!).
– Also – applying more lean principles to traditional Agile processes.

** Accurate estimate: this phrase is quite an oxymoron.

Estimation – a necessary evil

Recent conversations with some co-workers have prompted me to realize that both sides are equally right and equally wrong about the value that estimation provides.

Developers: Yes, it is what it is. Putting a number on a set of features will not change how long it will take to implement, test, and release. I think people understand that, and if they don’t then you should try to explain that to them. However, you do have to realize that without any idea of how large an effort something might be would result in a chaotic plan that would have no basis whatsoever. How else can one plan for the right amount of budgets, resources, or what expectations to set with say – users and marketing?

Asking for estimates, for these purposes – as long as managers understand that they are estimates, is only fair.

Project managers: The other side of the coin. Yes, estimation is important for the reasons outlined above. But, and I’m going to repeat myself – estimates do not (and can never) change the inherent amount of work that something entails. Estimates are only useful for high-level planning purposes when used with a list of risks and assumptions, and an understanding of queuing theory (which will help derive the right buffer sizes).

There is no substitute for actual velocity – and that is the only thing that is real. Also, accurate estimates is an oxymoron.

So there.