Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Agile Manifesto: Principle #1
Given the IT backgrounds of the people who developed the Agile Manifesto, it’s no surprise that their first principle focuses on early, continuous delivery of value.
At the time, IT programs were notorious for taking months and even years of time to deliver value, sometimes collapsing under their own weight before they delivered anything. Two related problems made value delivery excruciatingly slow: late systems integration and late customer feedback.
At the time, the much-maligned “waterfall” method assumed that the customers could deliver perfect requirements, the systems architects could deliver perfect architecture design, the database designers could deliver perfect schema, etc.
If all of those things were true, then all the pieces would come together at final integration and just work.
Final Integration Never Worked the First Time
Systems integration work was painful. The defects that couldn’t be caught by unit testing all popped to the surface at once, overwhelming developers and testers with bug reports. Since it had been months — and sometimes years — since the bugs had been introduced, they were hard to find. Sometimes fixing them caused other problems.
And that was just the code. Systems integration tests also found problems with things that were much harder to change in the architecture. And once users got the first version into their hands, they realized that they were not getting the software they expected — no requirements document, no matter how comprehensive, could account for all the stuff the users forgot that they knew about how things needed to work.
People attempted to do a lot of things to improve the quality of the requirements, the architecture and the code. But those things didn’t address the fundamental problem, which actually resides in the way that waterfall development structured the workflow: big batch releases.
Big Batches Are Inherently Slow
A “batch” is a collection of things all released at once, like a “batch” of cookies that are all baking at the same time in the oven. My oven can handle two baking sheets, each holding 12 cookies, so my cookie batch size is 24 cookies. If I let a batch of cookies stay in the oven too long, I’ve burned 24 cookies.
In my oven, it still makes sense to bake 24 cookies, and use a timer to make sure that I don’t burn them. That’s only because I know that my recipe makes good cookies, I know how to execute the steps in a repeatable manner, and the environment in my oven is relatively well-controlled. I can get predictable results.
But that’s not what development work is like. There’s too much uncertainty. Customers can’t always give you a good recipe — they may not know it until they taste it. Your “baking system” is also not proven. You don’t know if you’ve got good cookies until your customers have tried them, and you don’t know if you can always get good cookies from your baking system until it’s more stable.
In this environment, we want to work in small batches: here are a few cookies to try. How can we make them better? Now here’s an improved batch. What do you think of these? Meanwhile, your team is working to make your oven more reliable, and small batches help with that too, by giving you lots of opportunities to learn and iterate. You’ll find small problems before they become big problems.mYou’ll learn a lot more about baking cookies, and your customers’ preferences.
All of that smooths out the workflow for everyone from the people ordering the ingredients to the people mixing the dough, the people working the ovens and the ones who taste the cookies. In a commercial bakery, they will mix up large batches of dough from standardized recipes. But after that, they strive for a continuous flow of cookies from shaping to baking to packaging, because that’s how to bake a lot of cookies quickly. If the oven gets too hot or the packaging system gets jammed, fewer cookies have to be thrown away.
But waterfall development on a large-scale IT system is like baking thousands of cookies at once, from an unproven recipe, in a new oven that can’t hold nearly that many. It’s a near-certainty that something will go wrong, the cookies won’t taste very good, and the entire batch will need to be re-baked. It’s a tremendous waste of resources, so it’s no wonder that the Agile movement is on a mission to replace waterfall with early and continuous delivery of value.
Continuous Delivery Drives Down Batch Sizes
Teams that strive to deliver value continuously will naturally cut their batch sizes. In every cycle, a software team will choose a small number of things to do, based on what will deliver the most value. They’ll write User Stories to make sure they understand customer needs. They’ll update the architecture models to reflect the work they’re doing. They’ll write tests and code to validate that they’ve completed the User Story. Then they’ll demo the final result to the customer.
Agile software methods don’t actually deliver value continuously — there is a limit to how often teams can integrate, and how often they can release to customers. But they do strive to deliver shippable software at the end of every cycle of development, whether they call that a Sprint or an Iteration — to drive a new feature or user story to “Done-Done.”
“Done-Done” means that it’s done as validated by unit tests AND done as validated by system tests. It’s fully integrated into the working system, and not causing any major defects. The software could be released to the customer — although that’s not typically the way things work. Instead, teams demo the software to the customer to get valuable feedback on it. If changes need to be made, they can be done in the next Sprint or Iteration.
Instead of baking thousands of cookies in one giant batch over months or years, they bake a few cookies every four weeks. Instead of dumping a ton of cookies on all the customers at once and making them all sick, the team presents a small plate of new, fully-baked cookies to try and watches carefully as a representative customer eats them.
What Is “Continuous Delivery of Value” for Physical Products?
New physical products are not delivered continuously or even iteratively. Some markets can’t even handle one new product release a year. Most consumer markets can handle two, maybe three new product releases a year, in specific market windows.
Except in a few limited circumstances where teams can iterate rapidly on custom products they co-develop with their customers, hardware teams deliver tangible customer value only at the end of the commercialization process. But this does not mean that physical product teams can’t continuously deliver value — it’s just not value that a customer can experience right away.
The team designing a new continuous-flow oven will bake a lot of cookies by the end. But that’s an expensive way to test the oven’s ability to deliver consistent results. In early development, they’ll use simulations and models. Then they might use a simple cookie recipe that’s fast and inexpensive to test baking. The cookies may not taste good and may not even be edible. But those tests will build valuable knowledge that will lead to a better product.
All product teams strive to deliver the right product to the right customer at the right price, with sufficient quality and performance to meet and exceed customer expectations for value. In order to do that, they need to make wise decisions about everything from who their customer will be, through the features / functionality the product will have, to quality attributes such as reliability and service life.
To make wise decisions, the team needs knowledge.
The work of any development team in the physical or virtual space is the work of building knowledge needed to make decisions and execute them.
In software, the code itself embodies the knowledge that went into creating it, in a form that can be instantaneously replicated and transported. The time from decision to execution approaches zero. In the physical world, the decision is only the beginning, and we continue to build knowledge until the team’s decisions are fully realized as a product that a customer can buy.
Software teams deliver the code itself to customers, as apps or as firmware flashed into memory. Physical product teams deliver knowledge in many different forms to downstream partners who will source, manufacture and ship the product to the customer. Those partners need to have confidence that this knowledge will enable them to build a good product.
Continuous Delivery of Knowledge
The way that a physical product team delivers continuous value is through the early and continuous delivery of knowledge. Sometimes that knowledge will be in the form of artifacts like CAD models and physical prototypes.
But the value is not the CAD model or the prototype. The value is the knowledge that was created through building models and prototypes. It is only valuable to the extent that it moves the product design closer to release. Teams do many other things to generate knowledge, like user interviews or materials testing.
In the Rapid Learning Cycles framework, we support the continuous delivery of knowledge by focusing the team’s attention on the knowledge that needs to be created (Knowledge Gaps) to make their most important decisions (Key Decisions). At the end of every Learning Cycle the team shares the knowledge they have created and decides what they need to learn next.
This structure encourages them to continuously deliver the knowledge they need to deliver the right product, at the right time, at the right price.
The Right Time to Deliver Knowledge
Both Agile Software Development and Rapid Learning Cycles recognize that value delivery is distinct from documentation. Neither Agile Software Development nor Rapid Learning Cycles encourage teams to lock down requirements or freeze designs early in the name of delivering value.
A requirement that is not validated, an incorrect decision that must be changed later, or a design defect contributes no direct customer value in Agile Software Development and is less than worthless to a downstream production partner.
Later principles will explore the Last Responsible Moment as a means to ensure that the right value is being delivered at the right time. Many things will be finalized later than a “waterfall” process would require them to be finished.
The First Agile Principle recognizes that these are false markers of progress, because they contribute nothing towards the continuous delivery of customer value.
The First Agile Principle for Physical Products
The original formulation of the first Agile principle clearly focuses on the software world. Here’s how I would translate that principle for anyone developing a physical product:
Our highest priority is to satisfy our downstream partners and ultimately our customers through early and continuous delivery of the knowledge we need to deliver the right product at the right time.
To Learn More:
Achieve Agility with the Right Batch by Kathy Iberle, Rapid Learning Cycles Certified® Advisor.
