Thursday, December 31, 2009

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.

[image[3].png]

 

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.

 

image

 

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!

0 comments: