Monday, December 19, 2005


Software Development has absolutely zero to do with construction

Another very smart architect at work who happens to have my first name who is a believer in agile methods has been busy championing the incorporation of SCRUM into our lifecycle. I wonder if I could convince him to speak with others about dropping That Damned Construction Analogy...

A lot of folks at work and in my travels have adopted the notion of city planning. In private though, I think we agree that what we do is a lot more like gardening. Pretty much every single day we tend to our small plot making sure that things will grow. We put a lot of energy into pulling weeds and there sure is enough fertilizer to go around for us all.

In thinking about James Shore's post I can say that I definetely agree in principle but also think that the agile community oversimplifies the problems that large enterprises face. Martin Fowler is especially guilty of this practice. I wonder what it would get for those same folk to consider adopting transparency along with agility. That way, they can declare their consulting firm biases and the real benefits of agility will emerge.

Check out the Agile 2005 conference and notice how every single speaker is either a consultant or software vendor! Do you think there may be some bias here? Do you think at such a conference you will only hear a thinly veiled marketing message regarding agile without any perspective of what it takes to do in a large enterprise? Ever wonder why no agile conference ever invited a single person from any Fortune 100 enterprise to serve as keynote speaker? You should...

Don't get it twisted as I understand the power that agile methods can bring to an enterprise. I am simply asking for more transparency. I look at how other approaches such as Six Sigma and CMMi have grown. I believe their growth is due to the fact that it grew beyond its founding members. In fact, its founding members intentionally let it grow beyond them! Maybe the same thing is required of agile software development...

Let me get back to Jim's posting. Construction folk acknowledge that there are specialized disciplines even within the folks of the same title / job family. For example, there are carpenters that doing framing which are different than those who build other parts of the house and even those who specialize in trimwork. I wonder if enterprises that adopt agility should get the folks in HR to acknowledge that not everyone is pluggable unit?

These same construction people come and go when needed and aren't required to be sitting idle at the start of the project and attend weekly status meetings while the building is going up sitting on their hands waiting for their turn. I am currently having a drywaller mud-and-tape my basement as we speak. Since he is available, I was thinking about asking him if he could give me a hand at electrical work. After all, I would use the same approach at work if someone were idle. I guess experience doesn't really matter and hence the reason IT folks always blow budgets. I wonder how far my drywaller (his name is Mike) will tell me to shove it if I become persistent?

Another thought when it comes to construction is that they tend to estimate based on probable worst case vs what IT folks do in estimating which seems to be based on people x hours with the ceiling being how much money has been budgeted. The construction industry doesn't go around asking every single contractor to contribute their part to the estimate and instead have a full-time resource that has sole responsibility for estimation. I wonder how this notion would work in corporate America?

The one thing never spoken about within the agile community or corporate America is why the analogy of software construction has failed us miserably. I wonder though if there is a compromise. I was thinking that maybe if IT were to think like a business (this is different than aligning with the business) we would kidnap the construction analogies regarding construction and its relationship to IT work planning and instead think more deeply about how construction folks operate like business people!

Anyway, I know that several of my coworkers read this blog. I will followup in a future blog entry on whether I am successful in getting them to be the keepers of the flame and not only help themselves develop better working software but encourage others to do so by dropping the lame analogy of construction...

Links to this post:

Create a Link

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?