There are many analogies in use today to help teams understand the "delivering incrementally" part of agile processes. At the core, we struggle to take our silo'd views of software development into a cross-functional team that ships software. The idea that "code complete" doesn't ship to the customer allows everyone to come together to affect quality of the product. We drive the waste out of a team by focusing on what it takes to bring the working software from a developer's machine through to production in short iterations.
Imagine a recording studio. The team of individuals who come together to produce an album is our cross-functional team. We have a sound engineer, bass player, drummer, vocalist, etc...In the very beginning, the song-writer uses whatever medium to envision a song. Sometimes just the chorus comes to the writer and sometimes it is just a simple melody. I would call this person the Product Owner. They are envisioning the song we want to build and are working with various instruments to flesh out the design of the song. Sometimes the chorus and melody are enough to pass on to the musicians and let them elaborate; other times, the Product Owner wants to be more direct. When the Product Owner has decided that he would like a section produced, he can pass the design of the song on to the team. In many cases, the team can talk through the design and with the help of a Producer (Architect), they can begin breaking down the sprint backlog (the tracks) that they will use to create a vertical slice of that song (or perhaps the whole song).
Let's say they choose to start with the bass and percussion. This will usually set the tempo and structure of the song allowing the rest of the instruments to accompany the song and "fill it in". As they work through "tracking" the bass and percussion, the group will typically be listening and providing feedback as they try to adjust and iterate on the part of the song they are producing. Next, they might add some rhythm guitar and piano accompaniment to help fill the song in and give it more depth. As the team lays down the various tracks, they are testing it for tempo match, tonality, etc...Anything that doesn't sound right is scrapped and re-recorded. Once we have all of the tracks built for that section of the song, we then "master" that section by bringing all the tracks together to form one cohesive, potentially shippable, musical increment. Then, master the volume of each track and make sure they blend well together. We will then record the piece and present it to the song-writer for approval. They will provide feedback in which case the process will start over again to build additional sections of the song, or re-record the section we just produced based on the feedback.
In most cases, we would likely finish an entire song in the sprint, but there are times where the song is a much longer "epic" in which it has themes that we can work on in smaller increments to form together as one big song in the end. This analogy presents some of the same issues we face in software development. The idea of generalists and specialists. What if our bass player is sick today? Do we all just stop down and get nothing accomplished? Or can we have our guitar player (who is likely familiar with a bass guitar) substitute in their absence? There are certainly pieces of our team that we can limp along without and some that would be critical to our success. If the sound engineer is sick or absent this sprint, we will likely struggle a great deal in the production of our song. To mitigate that risk, we would have a few members of our team learn the basics of the trade (maybe as simple as just learning how to turn the equipment on so we can at least record). We can always re-master the track later when the expert sound engineer returns. The point is that we would want to make progress as much as we could and blur as many lines as we could on the bottleneck positions.
Once the song is complete, the Product Owner might decide to release it as a single, while we continue to record all the other songs to complete the album. At least the consumer has value of our song now even though the whole album is not complete. The idea is that we want to treat our software in much the same manner. We have to have great ideas that bring value to the customer. Therefore, we have to have a great Product Owner. We have to have a great cross-functional team that has all the abilities and skills required to get the software to a "Done" state each sprint, and for the people who are absent or missing (or too busy) we have to be able to move the ball forward. Each sprint we want to ship a vertical slice of the software so we can experience it for feedback. Short iterations allow us to respond and adapt to the changes so we produce a better product in the end.
In the end, we are doing exactly what Scrum as created for; breaking down complexity. The bigger things are, the less we know about them. Scrum allows us a natural process to constantly take large items and break them down smaller and smaller as their priority gets higher and higher. Use Epics to track the larger components and understand when they are valuable to the customer. It may take multiple sprints to get something into the hands of the customer, but that should not prevent us from gaining feedback in a solid state of "Done" each iteration. Yes, the Album is likely what the customer bought, but each song in the album is valuable on their own and can be played on the radio as a stand-alone piece. We should be able to deliver our products in much the same manner; providing incremental value to the customer along the way.
