Teams that don’t deliver working product frequently aren’t agile.
I hold firmly to this truth for many reasons. For example, how can we iterate on a product that isn’t real? Wouldn’t you agree that continuous improvement is at the heart of agility? So if the product isn’t real, how can we be sure we’re learning the right lessons? And how is “frequent” defined in this context? For that last question, read this blog post about metrics where I talk about what metric matters most. It’s a simple one and one that’s typically easy to measure:
How often are we delivering working code to our target environment?
So why does this even matter? What do these frequent deliveries get us? Here’s six reasons agile teams delivery frequently:
- Inventory is wasteful. Customers can’t benefit from a new feature–and we can’t profit from it–until it’s in production. If we attempt to build a horde of features at once, we may be able to utilize all “resources” at 100%, but we’re also tossing a crap ton of money at the problem and yielding no profit as we do so. Inventory hogs capacity, and the landscape may change before we can deploy our feature to our customers. Delivering frequently limits inventory and increases effectiveness.
- Status reports become worthless. Those red, yellow, and greens for each project become unnecessary when we’re showing everyone a working product frequently. After all, nothing shows progress better than a product I can touch, feel, and see, even one that’s primitive and incomplete. Consider this. Let’s say we were remodeling the kitchen. Each week, our contractor provided us with a color-coded, collated status report, but he refuses to show us the kitchen itself. Wouldn’t that worry you? Further, when we toss aside status reporting, we can repurpose that time to focus on the product. And isn’t that why we’re here?
- It reframes the conversation. “Are we there yet?!” As a parent, that question tries my patience, and I’d imagine I’m not alone. Similarly, teams are often bombarded with “when will this be done?” How distracting! However, if we’re delivering frequently, the question changes. It becomes “how can we make this better?” This reframing lightens pressure on the team and fosters more productive conversations.
- Plumbing is expensive and often overlooked. No team should wait until the eleventh hour to connect a system end to end, and the times that I’ve seen this done never ended well. Did it for your teams or did you also have delays and lots of late nights? There’s so much work in the crevices and in the shadows that is often ignored. We can choose to pay that cost all at the end or, if we’re delivering frequently, a little at a time.
- It simplifies the equation. In fact, it simplifies several equations. Want to limit blast radius? Deploy small batches of code so it’s clear what deploy mucked up the environment. (Of course, other methods like canaries help us in this respect as well.) Want to make small, affordable bets as to what features will excite the customers? Hypothesize and then deploy small changes that allow us to isolate variables to scrutinize customer behaviors. Want feedback quickly from users? Give them what they ask for so they can tell us what they really want.
- Scope, schedule, or resources. This is the iron triangle argument, and I still remember learning it from my CSM course many years ago. We’re handed a time frame to craft some new product and a budget to do so, leaving us to negotiate scope. Some might argue that scope is also locked in place, and if that’s true, stop reading this post, polish up your resume, and start hitting up connections for job leads. Anyway, to negotiate scope, we must have a mechanism for timely–better yet, frequent–product delivery so we can provide it quickly when we run out of time or money. Without it, we put ourselves at risk. Or as Douglas Adams puts it:
I love deadlines. I love the whooshing sound they make as they go by.
There’s so many more great reasons, but I’ll stop here for now. Before I go though, I’d like to give a special thanks to the folks at the Hands-On Agile slack channel for helping me with this post. Specifically, thanks to Stefan, Jonathan, Alex, Jamie, Bart, Sangeeth, Jasenko, and Rieks for their ideas. It’s great to be part of a community that gives back to those looking for a hand.
Do you want to get notified when new posts are published? Leave your email below.
