One of the arguments purporting to negate the logic of agile principles comes from the analogy of building a house. It is said that no one in their right mind would build a house incrementally - finishing a bathroom, then finishing a kitchen, then finsihing a bedroom etc. There's no value in the house until the entire house is finished, which is why they are constructed based on task sequence effeciency: all structural followed by all plumbing followed by all electrical etc.
After a conversation with a colleague, Brent Walker, it became clear to me that building NEW software is not analagous to building a house, it's analogous to building a housing subdivision. The subdivision is a system of houses just as software is a system of functionality.
Developers buy land and install basic infrastructure for the subidivision: roadworks, electrical, and waterworks. They then build and market houses one at a time to accrue value on their investment, tieing in the basic infrastructure to each house. They do NOT set out to finish all houses in the subdivision at once when the last finishing task (painting for instance) is completed on all houses. They serially accrue value one finished house at a time.
In continuing the anaology, the finished software application is the housing subdivision and the incremental valuable story is the house. Agile principles stress the importance of accruing incremental value by finishing stories one (or a few) at a time as early as possible rather than having them all partially finished at any given time (thus delaying value accrual). The bedroom or kitchen in any one of those houses is more akin to a task necessary to meet the acceptance criteria of the story.
Many software development projects are similar to house renovations; you want to add value while still accessing the existing value.
In June of 2013 a major (>100 year) flood in our town caused us to consider renovating our basement. We had to remove the flooring and strip the walls to the studs. In so doing, we also decided to reconfigure the space from a project room and large common room to two bedrooms and a smaller common room. Each area to be renovated required some framing, some electrical (lighting), sound insulation in the ceiling, drywalling, mud/taping, painting and cement floor polishing in order to be considered done.
After completing the electrical in all rooms and hanging the drywall in the first bedroom, the question arose as to whether effort should be spent finishing hanging drywall in ALL areas (both bedrooms and common room) before moving on to mud/taping, painting and floor-finishing or whether each room should be taken to completion in series. Mudding/taping all at once, for instance, would minimize the incidents of mess and dust inherent with the drywalling process. However, with only 6 weeks until Christmas, the entire basement could not be finished. It was decided it was more important to have both bedrooms ‘usable’ (drywall hung and providing at least visual barriers) before Christmas to allow for the bedrooms to accomodate likely holiday visitors; the Minimum Marketable Feature given the time constraint. The state of the common room in-between was less important and therefore effort was not spent hanging drywall in it. After Christmas, it would be more important to finish the bedrooms prior to the common room even though that would likely require more more instances of drywall dust/mess.
Performing one task across all rooms has the apparent value of being more efficient as there would be less context switching and less instances of disruption but taking that route also DELAYS the principle value of each of the bedrooms; having private spaces ready for use by holiday visitors.