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.)