Customers don’t always know what they want – or need. As Henry Ford once put it, if he’d asked people what they wanted, they would have said “faster horses.”
Of course, Ford gave them cars. But imagine if he hadn’t. Years would have been wasted trying to satisfy that demand. Chances are, by the time Ford’s product hit the market, someone else would have already started selling cheap, reliable cars. His product would have been dead on arrival.
We all have the same problem. That problem can be summed up in a single question: How do you deliver a valuable product to your customer, even if they can’t tell you what they really want or need?
One answer is the bundle of practices and principles known as agile. If you’ve heard that word before, you’ve probably also come across some related concepts – like scrum, kanban, XP, and lean. Oftentimes, there’s a temptation to rush into discussing these methodologies right alongside agile.
For Andrew Stellman and Jennifer Greene, the authors of Learning Agile, that risks putting the cart before the horse. There’s no point in getting into the nitty-gritty, after all, if we haven’t shown why you and your organization should even consider agile in the first place.
To do that, we’ll follow a project from start to finish. Along the way, we’ll see how agile principles can help a team of software developers work more efficiently and effectively – and deliver a better product.
You can’t design good software in a vacuum
Take e-readers for instance, like Kindle, It’s easy to see why they’re so popular. The object itself is about the size of a regular paperback, but it holds thousands of books. Even better, every text is responsive to you, the reader. You can enlarge the words, change the font, or skip back and forth between the main text and references. With a single click, you can access libraries and catalogs; with another click, you can borrow or download new books onto your device.
In short, this is great software. It’s well designed. Convenient. Intuitive. It satisfies every stakeholder. Readers find it easy to use, and it displays texts accurately, which is important to authors. It also helps booksellers and publishers sell and distribute books.
The first e-book readers didn’t do all these things, though. In fact, it took over a decade of development before the software got to where it is today. Back in the early 2000s, it wasn’t clear what would make an e-book reader valuable. We only know that today because hindsight is 20/20 – which brings us to our little thought experiment.
Let’s go back in time. Imagine we’ve been tasked with developing the software to display electronic books on brand-new handheld devices. How will we approach our task?
Well, we’re actually going to do it in the worst possible way because this isn’t the kind of company that’s exploring new ways of building software. This is an old-school operation, with leaders who lead and followers – that’s us, the developers – who follow. In short, this isn’t the kind of office where you’ll hear the word “agile.” So let’s see how things play out.
The hardware team has already made a prototype. Picture a chunky black tablet with a USB port for loading books and a fiddly little keyboard for interacting with the reader. It’s up to us to build the software that will display e-books on this gadget.
Our company applies what’s known as a waterfall process to its projects. What that means is that projects are front-loaded. All the product requirements are defined at the outset. As we said, leaders lead and followers follow. All the stakeholders – the senior managers, publishing representatives, online retailers, and so on – sit down and and hash out a plan. They outline requirements and come up with a specification that ticks all their respective boxes. Every other stage of the process, from design to development and testing, flows downstream from these decisions just as a body of water flows downstream from a waterfall.
So what’s in the specification? In a word, everything. This e-book reader is going to be revolutionary. It’s going to have tons of features. It’ll capture market statistics for publishers. It’ll have an internet storefront for readers to buy books. Authors will be able to preview and edit their books as they write them. And it’s all going to be ready in 18 months.
Fast-forward a year and a half. Since this is a thought experiment, we don’t have to be realistic, so we’ll say the project is completed on time. And it’s all there – every requirement in the specification has been implemented, tested, and verified. Everyone’s happy.
Can you guess what happens next? The reader hits the market . . . and it flops. Hard. No one buys it.
What went wrong?
The thing is, people’s needs aren’t static – they change with the times. If your only choice is a horse, you want a faster horse. But a horse, no matter how fast, isn’t much use if everyone else is already driving cars. Similarly, the software that people needed 18 months ago isn’t the software they need today. Since our project began, a new industry standard for e-books has emerged. No retailer wants to publish our unstandardized format – it’s too much bother. And so none of our revolutionary features are supported, which means they’re no use to anybody.
This also means we’ve wasted lots of time and money creating software that’s not very valuable. So what should we have done differently?
Release imperfect software today, & you’ll end up with a better final product tomorrow
Here’s where we went wrong: we were unresponsive. We spent 18 months working in a bubble to implement a plan that was out-of-date before it even reached the market. There were no adjustments. We weren’t flexible. Our project, in short, wasn’t iterative.
An iterative design process doesn’t take place in a vacuum. Instead, it rolls out products quickly, getting them to customers as soon as possible and gathering feedback. That feedback is the basis for improvements, which are then sent back to customers – again, as quickly as possible – so they can provide new feedback. At that point, the cycle restarts. To iterate, after all, means “to perform repeatedly.”
This feedback loop is at the heart of agile processes. Think about the word “agility” as we use it in everyday language. It describes a way of moving quickly and nimbly – of being responsive to the environment and engaging with what’s in front of you. An agile climber, for example, responds to every hand- and foothold they encounter. They make rapid adjustments to prevent slips and fumbled grips. It’s the same with agile in software design. Agile teams use iterative processes to respond quickly and nimbly to bugs and mix-ups as they encounter them. They might not build the software they set out to build, but that’s a whole lot better than building something useless.
So there’s the first principle of agile. We can phrase it like this: The highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Now, let’s break that principle down even further.
Software can only be built in the real world – the world of imperfect humans. Even the hardest working teams miss important details. The most talented developers fail to anticipate vital requirements. The only way we can correct mistakes is to put the software we’re building into the hands of customers – the people who’ll actually be using it. As developers, we’re entirely dependent on their feedback. That’s why we need to release software early.
Releasing software early isn’t just an antidote to perfectionism – it delivers value for customers. If they have a single feature today, however buggy, they can do something they couldn’t yesterday. By actually using a product, they can clarify their needs. That means they’ll be able to give us a clearer idea of what they want a product to do. And once we’re locked into this feedback loop, we’re on the road to creating a final product that actually satisfies those needs.
Embracing change is all about adopting the right mindset
So there’s the answer to the question we asked earlier – what we should have done is put our software into the customers’ hands, so they could actually use it and give us feedback. If we’d done that, we would have realized there was a problem and changed course. That would have saved us the time, effort, and money we put into building an expensive dud.
Of course, changing course midway through a project is easier said than done. In practice, it’s usually a painful and unpleasant experience. You’ve made the difficult decisions. You know what you’re building. You know what your customers expect. Your workflow is established. It’s not plain sailing, exactly, but you’re making progress. And then someone from outside the project comes along and says that you’ve been on the wrong path the whole time. That all that planning and work was for nothing. That you have to circle back and start again. Worse, the person telling you to change course is the same person who put you on that path in the first place! They told you to build one thing, and now that you’ve built half of it, they’re telling you to do something else. It’s demoralizing – disrespectful, even. No wonder you get defensive and resist making changes.
Understandable? Sure. Helpful? Not at all. The important question is though, how can you get past this feeling?
Well, it’s a question of mindset, and it has two parts. The first is accepting that it’s really hard to build valuable software if you’re not constantly checking – and revising – your priors. Yes, changing course halfway through a project is frustrating, but it’s nowhere near as deflating as reaching the end of a project and realizing you’ve built a piece of junk.
The second part is about perspective, and it takes the form of an exercise.
This isn’t always an easy exercise – it requires a cool head and more empathy than you might want to extend to the person who’s just ruined your day. But it can be illuminating. Start by asking yourself these two questions: First, did your customer deliberately send you down the wrong path? Probably not, right? And second, how did they feel when they realized they screwed up and cost you months of work? Chances are, they were pretty embarrassed. They probably didn’t want to come to you and admit their mistake. It’s a good thing that they did, though – they’ve just saved you even more wasted time! And it’s not just your deadline that’s been blown. Your client’s timeline is delayed now, too. Their company is spending good money to build software that meets its needs, and this mistake means the project isn’t delivering. In other words, this is frustrating for everyone.
When you get down to it, you’re both in a difficult position. The only way you could theoretically avoid screwups would be to read your customer’s mind. Your customer, in turn, would have to be able to predict the future. In an ideal world, you’d both be able to do those things. But software isn’t built in an ideal world; you won’t be working with telepathic clairvoyants. Accept that, and mistakes – along with the changes they bring – will be much easier to deal with.
Iterative processes keep you in touch with your customers
OK, let’s go back to where we started. How can the agile principles we’ve explored help our troubled e-book reader project? Let’s find out by running the project again.
First, let’s remind ourselves why that reader flopped. It lacked some important features used by competing e-book readers, like supporting an industry standard format. Note, however, that this problem couldn’t have been predicted – or avoided. When our team went to work, there was no industry standard. Our emphasis, then, has to be on the team’s responsiveness to what it finds out once its work has already started.
This time, the project is going to be agile. We’ll start with a big meeting where we’ll hash out the requirements and specifications, but we’re not going to stick to that plan for 18 months straight. Instead, we’ll divide that year and a half into one-month sprints – a single cycle of the feedback loop we discussed earlier. Put differently, we’re going to update our design in response to feedback every month.
There’s not going to be much to test at the beginning, of course, so we’ll fast-forward to the fourth sprint. When the project manager, team, and stakeholders meet, one of the developers reports that there’s a new industry standard for e-book formats. The team incorporates this new information into its next sprint and builds a library that supports the new format. By the sixth sprint, it’s ready to incorporate that format into the reader’s user interface.
As you can see, each sprint roughly maps onto each iteration or version of the software the team is building. So let’s skip to month eleven – the eleventh sprint and the eleventh iteration. We now have a working build, which can be loaded onto the prototypes the hardware team came up with. It’s buggy, but it’s good enough for real-world testing, which is exactly what the team wants. When the project manager talks to the software’s early users, she learns that they’d like to be able to email newspaper articles and PDFs to their devices. That’s the focus for the team’s next sprint.
This approach isn’t just about testing and incorporating new features, however – some features can also be discarded. For example, maybe that internet storefront doesn’t make sense. There’s a standardized e-book format, after all, so we don’t have to create a unique platform of our own. That’s handy because it frees up time to work on other, more important features.
This version of the project is much more likely to end well. We’ve been continuously releasing software for real-world testing and making timely changes in response to those tests. The big difference here is that we’re in touch with customers and users. When we used the waterfall process, we were completely sealed off from these groups once the project’s requirements had been approved. This time, though, we haven’t lost sight of our ultimate aim: building valuable, working software that satisfies real needs. And that’s the why of agile.
There are lots of ways of working agile, but every approach rests on the same core principals. The first is responsiveness. Agile processes are all about feedback. You don’t wait until the end of a project to test the software you’ve built – you get it out there as soon as possible. Real-world testing identifies problems early and helps your customer clarify what they need that software to do. The second principle? There’s no such thing as the perfect plan. Every project will require ad-hoc fixes, changes, and redesigns. But that’s a good thing – it’s how the best software gets built.