Small Iterations: The essence of agile

Someone asked me today “What is ‘Agile’?” and I found myself explaining something, that I feel some of us who use agile practices every day just take for granted now, that from the outside seem nebulous or just completely alien.

Wikipedia defines “agile”, as:

In software development, agile practices involve discovering requirements and developing solutions through the collaborative effort of self-organizing and cross-functional teams and their customer/end user.

It goes on to talk about responding to change, division of tasks and so on, and all of these are important concepts. But for me, the absolute essence of agile is small iterations.

To be agile is to be able to move quickly and adapt. If you work in small iterations, you can do this because you have lower risk and lower cost of change.

Imagine you have to build a house. You have to have it designed, do the groundwork, lay foundations, build the brickwork, get the roof on and the windows in and then start plumbing, electrical wiring, flooring, plastering and fitting out the interior. Then you have to decorate, at least to a minimum standard before you can move in. You have to build an entire house before you can obtain any value from it. Along the way you could make any number of bad decisions or suffer from design flaws that weren’t apparent at design time but reveal themselves during or after the build.

If you have never built a house before, all of this is a huge risk. You may only find out that the bedroom is too small for your needs, or that the windows aren’t soundproof enough when the entire house is built. This is why people employ experienced builders, who use tried and tested materials, designs and practices to build a house one “layer” at a time.

If I wanted to build my own house, it may be worth starting with building something smaller first. So – from an agile approach, perhaps I could build the basic structure of the house, but only completely finish the kitchen. In this way, I do a small “iteration” of work and I get a fully working, plumbed, electrified, decorated and fitted kitchen at the end of it. I can use the kitchen, I can figure out the things that worked well and didn’t work well, and apply this learning to the next room, which may be, say, the bathroom. Now, in practice, this is rarely a good approach to building a house – for a lot of reasons far outside the scope of this article – but the main one being that many people have built houses exactly like the one you want to build, many times. Therefore it’s a manufacturing project, rather than a development project – but hopefully the analogy is clear enough.

The benefit of, and a key principle of agile working is to work in small iterations. It is intended to improve a “development” project. One where you are creating something from scratch, that might later be mass produced or scaled. Make something that is totally complete, but small. Then iterate on this to build something a little more, something a little bigger etc… Use the learnings you gained from the previous iteration to guide your work on the next one. Importantly, at the end of each iteration – you deliver value. You deliver something that is complete and working. Sure, I want a whole house, but if I have a kitchen, I can cook meals, wash myself (not well) and sleep on a couch or on the floor. I have value, I have learnings and I can take what I’ve learned and apply it to the next piece of work.

One of the reasons large IT projects (think huge digital transformation undertakings in the public sector for example) end up hugely over budget, over time and grossly inadequate for the needs of their users is simply the distance (in both time and space) between the gathering of requirements, and the delivery of value. If you can shorten both of these – bring the people doing the work closer to the end users (if not physically, then at least in terms of communication channels), and shorten the time between identifying requirements and delivering value, you get immediate improvement.

Scrum is a framework for agile project management that embodies this principle really well – but you don’t have to practice Scrum to realise that small iterations lower risk, reduce waste and deliver more value.

Imagine you’ve decided to design and make your own wedding invitations. You need to design them, print or hand-make each one, then put them in envelopes, address the envelopes and post them. You could take a “production line” approach, and make all of the invitations, then put all of the invitations into envelopes, then address all of the envelopes, then apply postage and drop them off a the post office. The risk here is that any one of these processes doesn’t go well. If you have 100 guests, you now have 100 problems. If you make one invitation, add it to the envelope, address the envelope and post it, you’ve successfully proven that each part of the process works. You’ve eliminated the risk of the envelope being too small, or the glue on the flap being too weak, or your intended postage being insufficient – or even, forgetting whose invitation is in which envelope! You delivered value quickly. One person successfully got a complete invitation. Now you can take what you’ve learned and scale it up. If something changes during the process, you can quickly adapt.

What could you change in your organisation to make work iterations smaller and increase the value generated for your stakeholders?