Thanks to the Lean Startup
movement, Iterationless Development and Continuous Deployment
have become the New New Thing in software development methods.
Apparently this has gone so far that “there are venture firms in Silicon
Valley that won’t even fund a company unless they employ Lean startup
Although most of us don’t work in a Web 2.0
social media startup, or anything like one, it’s important to cut
through the hype and see what we can learn from these ideas. One of the
most comprehensive descriptions I’ve seen so far of Iterationless
Development is a (good, but buzzword-heavy) presentation by Erik Huddleston
that explains how development is done at Dachis Group, which builds
online social communities. The development team’s backlog is updated on a
just-in-time basis, and includes customer business requirements
(defined as minimum features), feedback from Operations (data from
analytics and results of Devops retrospectives), and minimally required
Work is managed using Kanban WIP limits
and queues. Developers create tests for each change or fix up front.
Every check-in kicks off automated tests and static analysis checks for
complexity and code duplication as part of Continuous Integration. If it
passes these steps, the change is promoted to a test environment, and
the code must then be reviewed for architectural oversight (they use Atlassian’s Crucible
online code review tool to do this).
all of the associated change sets have been reviewed, the code changes
are deployed to staging for acceptance testing and review by product
management, before being promoted to production. All production changes
(code change sets, environment changes and database migration sets) are
packaged into Chef recipes
and progressively rolled out online. It’s a disciplined and
well-structured approach that depends a lot on automation and a good
tool set.Death to Time Boxing
makes Iterationless Development different is obviously the lack of time
boxing – instead of being structured in sprints or spikes, work is done
in a continuous flow. According to Huddleston, iterationless Kanban
is “here to stay” and is “much more productive than artificial time boxing”.
In a separate blog post, he talks about the death of iterations
While he agrees that iterations have benefits – providing a fixed and
consistent routine for the team to follow, a forcing function to drive
work to conclusion (nothing focuses the mind like a deadline), and
logical points for the team to synch up with the rest of the business –
Huddleston asserts that working in time boxes is unnatural and
unnecessary. That the artificial and arbitrary boundaries defined by
time boxes force people to compromise on solutions, and force them to
cut corners in order to meet deadlines.
I agree that time boxes
are arbitrary – but no more arbitrary than a work day or work week, or a
month or a financial quarter; all cycles that businesses follow. In
business we are always working towards a deadline, whether it is hard
and real or soft and arbitrary. This is how work gets done. And this
doesn’t change if we are working in time boxes or without them.
iterationless Kanban, the pressure to meet periodic time box deadlines
is replaced with the constant pressure to deliver work as fast as
possible, to meet individual task deadlines. Rapid cycling in short time
boxes is hard enough on teams over a long period of time. Continuous,
interrupt-driven development with a tight focus on optimizing cycle time
is even harder. The dials are set to on and they stay that way.
Kanban makes this easy, giving the team, and the customer and
management, the tools to continuously visualize work in progress,
identify bottlenecks and delays and squeeze out waste – to maximize
efficiency. This is a manufacturing process model remember. The
emphasis on tactical optimization and fast-feedback loops, and the
“myopic focus on eliminating waste” is just that – short-sighted and
difficult to sustain.
With time boxes there are at least built-in
synch points, chances for the team to review and reset, so that people
can reflect on what they have done, look for ways to improve, look ahead
at what they need to do next, and then build up again to an optimal
pace. This isn’t waste. Cycling up and down is important and necessary
to keep people from getting burnt out and to give them a chance to think
and to get better at what they do.
Risk is managed in the same
tactical, short-sighted way. Teams working on one issue at a time end up
managing risk one issue at a time, relying heavily on automated testing
and in-stream controls like code reviews. This is good, but not good
enough for many environments: security and reliability risks need to be
managed in a more comprehensive, systemic way. Even integrating feedback
from Ops isn’t enough to find and prevent deep problems. Working in
Agile time boxes is already trading technical risks for speed
and efficiency. Iterationless Development and Continuous Deployment,
focused on eliminating waste and on accelerating cycle time, pushes
these tradeoffs even further, into the danger zone.
also critical of “boxcaring” – batching different pieces of work
together in a time box – because it interferes with simple
prioritization and introduces unnecessary delays. But batching work
together that makes sense to do together can be a useful way to reduce
risk and cost. Take a simple example. The team is working on feature 1a .
Once it's done, they move on to feature 1b, then 1c. All of this work
requires changing the same parts of code, the same or similar testing
and reviews, and has a similar impact on operations. By batching this
work together, you might deliver it slower, but you can reduce waste and
minimize risk by delivering it once, rather than 3 times.Iterationless Development Makes Sense…
Development using Kanban as a control structure is an effective way to
deal with excessive pressure and uncertainty – like in an early-stage
startup, or a firefighting support team. It’s good for rapid innovation
and experimental prototyping, building on continuous feedback from
customers and from Operations – situations where speed and
responsiveness to the business and customers is critical, more important
than minimizing technical and operational risks. It formalizes the way
that most successful web startups work – come up with a cool idea, build
a prototype as quickly as possible, and then put it out and find out
what customers actually want before you run out of cash. But it’s not a
one-size-fits-all solution to software development problems.
software development methods are compromises – imperfect attempts at
managing risks and uncertainty. Sequential or serial development methods
attempt to specify and fix the solution space upfront, and then manage
to this fixed scope. Iterative, time-boxed development helps teams deal
with uncertainty by breaking business needs down into small, concrete
problems and delivering a working solution in regular steps. And
iterationless, continuous-flow allows teams to rapidly test ideas and
alternatives, when the problem isn’t clear and nobody is sure yet what
direction to go in.
There’s no one right answer. What approach
you follow depends on what your priorities and circumstances are, and
what kind of problems and risks you need to solve today.