Can Agile Development Practices Produce a Signature Cookie Recipe?
Debbi Fields, Wally Amos, and I have something in common: we each have our own distinctive cookie recipe. Of course, their brands, Mrs. Fields and Famous Amos,are household brands; whereas, my cookie is just notorious among the relatively small number of people who have eaten my cookie.
By way of background, I’m a formally-trained chef with an economics degree and a knack for leading agile teams in designing software and solving complex problems. Software development lets me exercise both my right and left brain, but I’d really love to go the route of Debbie Fields and Wally Amos: if not with my cookie recipe, then with any of the other signature recipes I’ve got up my sleeve.
Iterating Towards a Recipe
I’ve been working on a cookie recipe for years, and it’s taken a somewhat Agile approach. You may say I’ve been working on the user story, “As a chef, I want to create a cookie that’s so delicious and distinctive that people will crave my cookies and pay me to make my cookies for them.”
I didn’t start out by doing a bunch of math formulas and writing down what I felt was the perfect recipe.
Instead, in preparation for the first batch, I weighed out the basic chocolate cookie ingredients (flour, baking soda, sugar, brown sugar, salt, vanilla, butter, eggs, and other super top secret ingredients) in grams. I made sure I had more than I needed, but minimized the amount I’d have to put back into a container or waste.
I also didn’t include chocolate chips because they’re expensive and I just needed to see how the dough portion changed in the oven: how was the spread? was it chewy enough? did it rise the right amount? The chocolate chips would contribute significant expense to my experiments without adding much information about the final output. If you consider that the chips were part of a “Chocolate Chip” user story, they were ranked lower priority; they were a feature that could be added later with minimal rework of the first set of stories.
At this point, all I had was a vision for the cookie.
Once I had my ingredients weighed out, I started the typical process: creamed the butter with the sugars and salt, added the wet ingredients, and then started adding the dry ingredients. I added by a fair amount of my allotted flour, mixed it in, then inspected it. I added a few spoonfuls more and inspected again. When I thought I had the right consistency, I baked it to see how it turned out. After two or three iterations of this process, I arrived at a result I liked and I wrote down the difference between the initial ingredient measurement and the remaining amount of the ingredient. This formed the basis for my recipe.
During this phase, my measurements weren’t at all precise: it was a gut feeling. If fact, I intentionally didn’t measure because I didn’t want to subconsciously add amounts that conformed to what I’ve been taught are “ideal” butter:sugar:flour ratios for different types of cookies.
At the end of this phase, I had just enough information to allow me to perfect the recipe and move to the next stage. My measurements were accurate, but not yet precise.
On the next batch, I started from my written recipe and purposefully and thoughtfully tweaked percentages of ingredients to adjust specific ratios of ingredients (flour:butter:sugar). I delved deeper into the details, and worked until I had measurements to a precision of 0.1g.
At this point, I had a very solid idea of what I wanted to make, and I was confident I had enough information to bake exactly the cookie I wanted to make.
Here’s where my current journey ends. I’ve been in sprint execution for awhile. Each time I bake a few dozen cookies for people, I’m executing sprints and doing sprint reviews with various friends, family, and coworkers. Gathering input, hearing what people believe is good or bad about the cookie, and potentially making changes in the next sprint.
Each batch is potentially shippable. I’m closer to knowing what it would take to make the cookies production ready, but I’m not quite there.
If I were to take my cookies to the next level, I’d need to do some performance load testing.
The recipe is perfect right now: it’s repeatable and produces the same results. My unit tests tell me that the recipe is working on a small scale, and user acceptance tests have shown the quality is correct.
However, my ingredients have a maximum of four significant figures, because I’m only measuring less than a kilogram of any ingredient to a precision of 0.1 gram.
Let’s say my recipe calls for 302.5 grams of flour, and I want to make my cookies for the masses, so I need to make a 10,000x batch. The 302.5 grams I’m measuring may in reality be 302.5124. If I were to make a 10,000x batch, the recipe wouldn’t be right unless I used 3,025,124 grams of flour. It may be close, but it wouldn’t be perfect.
Once that final piece of testing and preparation for launch is complete, there’s only one step left: launch the product.
Agile Principles Have Broad Application Possibilities
Agile development principles can be applied to just about any problem. Even if the Scrum ceremonies aren’t present, the Agile process can be applied to iterate towards a desired end result. One of the key parallels in this analogy is that the level of precision increases at each step. With the cookie recipe, I’m getting ever closer to knowing the actual recipe with a much finer precision at each step. At some point, if I were to go into business selling my cookies, the recipe would be known.
In a software development project, we get ever closer to knowing the actual delivery date, features, and cost of the project at each step. Once the project is delivered, those three things are known. If you find yourself thinking about how many hours something will take to do during the Release Planning phase, you’re likely too deep into the weeds and it’s time to pull back. You’ll figure out how many tenths of a gram of flour belong in the recipe when it’s time. For now, just make sure your general ratio is close enough.