Agile Software Construction is Like Neighborhood Construction

In my last article, I commented on Dr. Jan Chong's dissertation presentation "Software Development Practices and Knowledge Sharing: A Comparison of XP and Waterfall Team Behaviors". I raised some questions about the utility of long-term design documents and provided links to Scott Ambler and Mary Poppendieck's writings about unit tests and automated tests as a form of long-term executable specifications.

In this article, I'm going to give a better version of an often heard analogy that "Software construction is like building construction". Usually you hear this when product owners, project managers, or architects say things like, "We can't do that until we've got the foundation in place. Think of a building. You have to have a solid foundation first."

OK. Maybe so, but you only need it for the very first independent feature, and you should be building features as independently as you can. Here's why:

The Simple Building to Software Analogy

Here is a simplified one-to-one comparison that maps the "layers" of a building to the layers of a software application:

Building Component	Software Component
Furnishings	User Interface Layer
Internal Structure	Business Logic Layer
External Structure	Data Access Layer
Foundation	Database
Blueprints	Requirements Specifications

Traditional Versus Agile Software Development

To prepare my final point, I present the following two slides come from the Autumn of Agile screen-cast series mentioned in prior posts.

This first slide depicts the traditional sequential waterfall approach to building an application. The main theme is that waterfall projects typically result in teams developing horizontal layers that end up delivering business value only after all layers are complete.

 

This next slide depicts how agile (or simply iterative & incremental) projects develop systems. The main idea here is that features are developed vertically. This means that the features are independently valuable, and can represent a portion of the total desired value at any time should the project schedule get cut short.

 

 

Neighborhoods Get Built Using Agile, Not Waterfall

Let's assume we have 5 total features in the software system depicted in slides one and two. In the first slide, all 5 features are "finished" at the same time when the user-interface is built on top of the lower layers. In the second slide, a single feature is built from "top to bottom" during each iteration.

Can You Say Fffired?

Imagine a team of developers building a neighborhood like the traditional sequential waterfall approach to building software. Let's assume each iteration is 5 weeks for simplicity's sake. After 5 weeks, the developers would have built 5 separate sets of blueprints for the 5 houses to be built. Imagine that these are 5 or more separate parts of an overall software requirements specification in a software development project. They might describe database table schemas, relationships, multiplicities, etc.

	Week 1	Week 2	Week 3	Week 4	Week 5	Elapsed Weeks
Iteration 5						25
Iteration 4						20
Iteration 3						15
Iteration 2						10
Iteration 1	Blueprints	Blueprints	Blueprints	Blueprints	Blueprints	5

I'm sure you already see how asinine this approach to neighborhood development is.

Nevertheless, let's continue with the next 5 weeks and see how far our team has gotten toward delivering the first "potentially habitable housing increment":

 

	Week 1	Week 2	Week 3	Week 4	Week 5	Elapsed Weeks
Iteration 5						25
Iteration 4						20
Iteration 3						15
Iteration 2	Foundation	Foundation	Foundation	Foundation	Foundation	10
Iteration 1	Blueprints	Blueprints	Blueprints	Blueprints	Blueprints	5

After 10 weeks of work, our construction company has failed to complete a single inhabitable house. What are we paying these people for? Why are they building a foundation, then moving to the next lot to build the next one? I guess they're just going to get back to it sometime later.

Let's just speed ahead and see what we have after 25 weeks on the project:

	Week 1	Week 2	Week 3	Week 4	Week 5	Elapsed Weeks
Iteration 5	Furnishings	Furnishings	Furnishings	Furnishings	Furnishings	25
Iteration 4	Internal Structure	Internal Structure	Internal Structure	Internal Structure	Internal Structure	20
Iteration 3	External Structure	External Structure	External Structure	External Structure	External Structure	15
Iteration 2	Foundation	Foundation	Foundation	Foundation	Foundation	10
Iteration 1	Blueprints	Blueprints	Blueprints	Blueprints	Blueprints	5

This is great, finally. After 25 weeks we finally have inhabitable houses! Actually we had one inhabitable house after week 20, then one more per week until 25. That almost feels like a privilege at this point to get so many houses finished so quickly in succession.

Not in My Backyard!

Do construction companies ever really build houses like this? Not that I've ever seen. They try to complete a house as quickly as they can after the foundation concrete sets. Of course, that means they may indeed start on a second foundation before they build the remainder of the first house, but you get my point.

Suppose it were 30 houses instead of 5. Could you imagine if this were a new neighborhood being built just behind your backyard. What would you think if you saw the crews building 30 separate foundations, then coming back to the first to frame it, then moving to the next to frame it, etc, etc. You'd think they had last their minds or have absolutely no respect or understanding of the Time-Value-of-Money or concern for a Return-On-Investment.

Neighborhood Construction is More Vertical, Like Agile

As you can see below, our construction crew progresses through each house from "the ground up", which means that they finish one house completely every five weeks. This, in agile terminology, is their velocity per iteration. The learn more about agile teams and velocity, read my article "D = V * T : The formula in software DeVelopmenT to get features DONE".

	Iteration 1	Iteration 2	Iteration 3	Iteration 4	Iteration 5
Weeks Elapsed / Houses Completed	5 : 1	10 : 2	15 : 3	20 : 4	25 : 5
Week  5	Furnishings	Furnishings	Furnishings	Furnishings	Furnishings
Week 4	Internal Structure	Internal Structure	Internal Structure	Internal Structure	Internal Structure
Week 3	External Structure	External Structure	External Structure	External Structure	External Structure
Week 2	Foundation	Foundation	Foundation	Foundation	Foundation
Week 1	Blueprints	Blueprints	Blueprints	Blueprints	Blueprints

Comparing Velocity between Waterfall and Agile Approaches

In the following table, we're looking at how many houses we complete per iteration.

So, the calculation is number of iterations passed / number of houses completed.

Thus, the agile velocity is constant in terms of 5 weeks. We can always count on 1 house becoming complete every 5 weeks.

	Total Completed Under Waterfall	Waterfall Velocity per Iteration	Total Completed Under Agile	Agile Velocity per Iteration
Week 5	0	0	1	1
Week 10	0	0	2	1
Week 15	0	0	3	1
Week 20	0	0	4	1
Week 25	5	1	5	1

Combining Return on Investment with Velocity

Finally, since we know that nobody can live in a house until it's completed, we can calculate the potential accrued Return-on-Investment (ROI) after each iteration for actually having sold houses.

Let's assume we can sell each house for $100,000.

	Potential Waterfall ROI	Potential Agile ROI
Week 5	0	$100,000
Week 10	0	$200,000
Week 15	0	$300,000
Week 20	0	$400,000
Week 25	$500,000	$500,000

Taking into account the Time-Value-of-Money (TVM) we understand that it's certainly more valuable to realize returns via the agile approach to building neighborhoods as opposed to the waterfall method!

Similarly, when we talk about ROI and TVM regarding software projects developed using agile methods, certainly we sometimes mean that we can gain monetary returns earlier by producing "potentially shippable product increments" faster and getting them to the market. However, what we also mean is that by focusing on building features top-to-bottom, we can get the complete experience and feedback necessary to then apply toward the next feature and we prevent the pains of having to refactor code later when it's no longer fresh and when requirements have been changing all round.

Here is a good video on YouTube which depicts this relationship between time and value accrual very well:

Until next time, stay agile, not fragile!