I spent the majority of the July 4th weekend playing sous chef for my wife who was making cake for a friend’s wedding that weekend. The tricky part of this task was that instead of one, large-tiered cake, our friend wanted individual-sized square cakes. Wrapped in fondant. For 100 people.

For those of you keeping score at home, that means rolling out 100 baseball-sized balls of fondant into sheets less than a centimeter thick. Putting the fondant on the cakes took just as long as rolling each piece of fondant out, so I was volun-told to roll the fondant. Rolling fondant is certainly not how I wanted to spend the couple of days after July Fourth, but agreeing to would ensure domestic tranquility.

I am not good at decorating or many crafty related activities—probably why I made the career choices I did—but here I was trying to help my wife cover 100 small cakes with fondant. The first twenty-five or so were not very pretty. It didn't help that my wife was trying to remember exactly how much fondant she needed for each cake. I would roll out fondant for one cake while she put the fondant I had just rolled on another cake. She was not shy about providing feedback about my rolling skills—or lack thereof—and several times said she would just have to do it all herself. I was tempted to let her do that, but I realized that would lead to a few rough days in the McDonald household, so I persevered.

Finally, we made a breakthrough when my wife realized that we needed a lot of extra fondant (almost twice than what we started out with) that she would cut off and I could roll back into the fondant for the next cake. That breakthrough really helped our progress. I still received plenty of feedback and continued to make adjustments, but the remaining seventy-five cakes went much quicker than the first twenty-five, and we hit a good flow. We managed to finish the cakes with a couple of hours to spare.

So what does all of this have to do with software development? When we were done with the first fifty cakes and had to stop because we had ran out of fondant. I looked at my wife and said, "We just saw the advantage of agile approaches."

"How so?" she asked. My wife works as an analyst at a cloud-based service company, so she was familiar with the concept of agile.

"Well, since we did one cake at a time, I was able to use your feedback to adjust how I rolled out the following pieces of fondant. Had we tried to roll out a bunch of pieces of fondant first, we would have had to redo a lot of them because I would have rolled them all the same way and they all would have been wrong."

"Hmm," my wife said. "That's interesting."

I share this story because it embodies one of the key ideas underlying agile approaches: iteration. When you are building something you can break down into multiple small chunks, such as the many cakes we were making for the wedding, you are much better off doing one all the way through the process; what you learn from building that piece you can apply to the next one. In the fondant example, I could roll out a sheet of fondant, but we didn't really know if it was going to work until my wife put the fondant on the cake—until she used the fondant sheet.

Once she used the sheet, she provided immediate feedback—sometimes with a bit of frustration. I was immediately able to use that feedback to adjust my approach going forward. I made quite a few shifts that went on either side of the optimal combination of amount of fondant, rolling technique, and width of the fondant sheet but always used my wife’s feedback to get back on the right size and width.

The value in doing things in small iterations or using single-piece flow is the learning that occurs between each iteration—or each piece. Of course that learning only occurs if the people whose needs are being satisfied (my wife) can quickly try out the solution (the fondant) and immediately provide feedback to the people satisfying the need (me); the people satisfying the need get the chance to discuss the feedback they received and make the necessary changes. In agile approaches the techniques of iteration, demo, and retrospective are intended to ensure this happens.

Those techniques are a means to an end to get to inspection and adaptation. Teams new to agile (and even some that have been “doing agile” for quite a while) forget because they fall into the trap of cargo-cult agile and lose sight of why they are using those techniques. Teams get hung up on when to do a demo, how to do it, and who should be included. What they don't consider when having these discussions is why these techniques exist. I've come across several teams that held demos without any stakeholders, which means that they did not get the feedback they needed to make changes to the way they were doing things. This is the equivalent of me creating a fondant sheet, putting it on the table on which my wife was working, and then starting to roll out the next fondant sheet, ignoring everything my wife had to say about the previous sheet.

When I help teams adopt agile, I find one of the most frequent conversations is that it’s not really a matter of the “right” or “wrong” way to adopt agile, rather it is all about understanding why specific techniques make sense in specific situations.

I understand that teams often need to have fairly clear instructions for when they first start out. After all, it's best to start with clear instructions, but it seems like many teams never evolve beyond that point to make decisions on process changes based on what they are really trying to accomplish. They become slaves to the techniques with no clear understanding of why they use them. To be truly effective, teams need to focus more on the need to reflect and adapt, and then figure out the best way to do that in their environment without worrying about whether they are doing it exactly right. Once they do that, they can have their cake and eat it too. (Sorry, I couldn’t resist that one.)