Kent McDonald shares with us a story about decorating cakes and how that relates to doing agile the right way. 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.
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.