Thursday, February 16, 2006

Construction Time Again

Construction is nothing like software engineering and construction management is nothing like software project management. Jim Shore has told you so.

I was sitting in a seminar presented by a popular agile tools vendor recently [<cards on the table>These people have a product that competes with Team Foundation Server but this fact hasn’t affected my opinion on what follows.</cards on the table>] and then… , I was suddenly set in to an involuntary spasm of cringing when the presenter said “Now imagine we were going to build an agile house” and went on, “If we were building it in iterations, we might decide to build the bathroom in the first iteration, and then the kitchen in the next iteration.”

Now the agile landscape is changing but shame on us for continuing with this misleading idea. There might be ways you could bring agile ideas to house construction but it isn’t the idea of building one room at a time. The answer is to pipeline work and delivery of materials. There is already the Lean Construction Institute and a movement for lean project management in construction led by Greg Howell and Hal Macomber. Truly self organizing construction can lead to a bazaar or a shanty town. An in-depth analysis of how unplanned ordinary development evolves over time is described in The Structure of the Ordinary by Habraken, while adaptive construction that reacts to changing requirements over time is well documented in How Buildings Learn by Brand.

From the agile manifesto, the only value that immediately jumps to mind as appropriate for home construction might be customer collaboration over following a plan. I fail to see what individuals and interactions over processes and tools, or working software over comprehensive documentation, have to do with construction (as we find it today, and I don’t know enough about to solve those problems for them.) I think a vague case can be made for responding to change over following a plan but who would seriously contract with a construction company without an agreed plan. A garden shed, maybe, but a full house? C’mon, let’s get real! 

So at this year’s Agile Conference closing dinner, let us make it more than a party and invite Jim Shore to give us two minutes, warning us of the dangers of the construction analogy and then have the audience take a pledge, that although we love, in itself, the idea that agile construction is possible we recognize that it is a different medium from software and must adopt its own practices that reflect the medium and nature of the work, the tools, the raw materials and the supply chain.

Everything counts in this difficult job of articulating the evolving agile story. We just simply need to shake the disease of using construction as an analogy for software development.

[Update: Glen Alleman continues to argue in his Herding Cats blog that I’m confused. Glen adds something to the conversation observing that an agile approach to construction ought to be possible and desirable. However, he misses the point that construction and software development are two different mediums. His focus is only on project management, while mine is on the technique of how software is built. You can’t refactor a house very easily, nor do you check it in every night before you go home, or test its integration continuously. You specify, architect, design, build and test software completely differently from construction projects. Both the engineering approach and necessarily the project management approach are different. Glen asks if I’ve ever worked on a construction site, to which I’d reply, if he wants us to take him seriously as a commentator on building software, he might like to provide some evidence that he has written commercial software and is knowledgeable in the topic.

Getting back to the agile house analogy, it might be better if the first iteration provided shelter, the second heat, the third the non-functional requirement of robustness in all weather, the fourth water, the fifth light, and so on. At each stage the house is providing a valued function at the end of the iteration. Staying with the example from the seminar, a bathroom on its own does not function as a house. At best it might be a privy in the wilderness - that bizarre invention known as a backwoods latrine - but it isn’t a house.]

[So how many of you aging 80’s college/alternative music fans found a hidden layer in this post? Jim Benson got it and subtly added to it in his comment. Bonus points if anyone can spot the odd man out!] Technorati Tag: David+Anderson, Agile, Jim+Shore, Lean+Construction, Hal+Macomber, Greg+Howell, Glen+Alleman

Monday, December 26, 2005

Burning down the Christmas card list

It’s been a recurring theme for me in recent years - the idea that we (humans) are naturally programmed to look for transaction cost optimization that naturally leads to large batch sizes and “waterfall” thinking.

This year like any other year, we spend many an evening in December working on our Christmas card list. The first task is to update the information. The data is perishable. People move. Relationships change. Names change. People we haven’t heard from for years get dropped from the list and new names added. My wife and I have lived around the World in the past 15 years. Between us, we’ve managed to live in Oxford, Toronto, Hong Kong, Singapore, Dublin, Dallas (Tx), Overland Park (Kansas), and Seattle, besides our native Scotland and Japan. We’ve picked up a lot of friends and colleagues with whom we keep in touch mostly just that one time a year.

It is interesting to compare my process against my wife’s. After gathering an updated list, together with a set of cards, a set of photos of the kids, and stamps, I dutifully write a single card, address the envelope, insert the photo, seal the envelope and stamp it for sending. On a single sitting I might write 10 cards. Cards seldom depart without a personalized hand-written note inside. It’s an effort. I manage to find the energy about two nights per week. My cards are sent off in batches of about 10, perhaps twice a week, starting in early December. I concentrate on the overseas ones and those that require the most detailed notes first. My wife has the same labor input and same quality of finish but she first addresses all the envelopes, then she writes every single card, then she adds the photos, then she stamps them and finally sends them in one single batch. Her large batch of cards is dispatched towards the 3rd week in December with some doubt as to whether the longer traveled cards will make it before Christmas. The saving grace being that few of the recipients are from a Christian tradition and hence they have a tolerance to receive the cards before or around New Year rather than Dec. 25th.

My wife’s “efficiency” driven preference - you have to know her and her focus on economics - leads to a pure “waterfall” large batch transfer system with all the value delivered in one large batch at the end, and additional risk of late delivery to some of our friends. My iterative, flow of value approach, gets some cards on their way as early as the first week in December. Risk is mitigated. However, it is possible that my iterative small batch size approach does involve more energy expenditure. Regardless, all my cards made it to their destinations before December 25th. And had I run out of energy mid-Month (my job at Microsoft has been busy recently and the commute long and tiresome) then at least half my list (those furthest away and generally my more important family and old friends) would have received their cards.

Is my approach counter-intuitive? Or is the large batch size, more efficient (batch size over transaction cost) approach the natural way for the human race?

Wednesday, July 27, 2005

Stretching Agile to Fit CMMI Level 3

Here is the paper and the presentation slides that I presented today at the Agile 2005 conference.

Download Stretching Agile to Fit CMMI Level 3 - the story of creating MSF for CMMI Process Improvement at Microsoft [Paper PDF 342K] [Presentation PDF 829K]

I have to say that I was very pleased to see the room full - there is so much great stuff at the conference and to get 30 or 40 people for a CMMI experience report was a really good turnout. The audience also really seemed to like the presentation and greatly appreciated the work we’ve been doing to articulate the intent of the CMMI and make agile software development practices acceptable to the appraisal community.

[Update: Dec 14th 2005. I got some review comments from Jon Gross at the SEI. I’ve incorporated most of Jon’s comments and issued an updated version of the paper 1.6]

Sunday, February 20, 2005

MSF for Agile Software Development

My colleague Randy Miller finally got the second draft of his new agile process out the door. We’ve created a new space at MSDN to house it and the debate around it. Go check it out.  I’d encourage you to download it. Take a look. Please provide all the feedback you have the energy to supply. We’ll have another rev of this before the product ships later this year. So here is your chance to have an influence on Microsoft’s agile offering.

Today, I presented the newly named MSF for Agile Software Development at Web Services Edge. At this conference, Visual Studio Team System was being shown everywhere. Before my presentation, there was a two-hour .Net mini-tutorial where the latest modeling capabilities were shown in a live demo. We also had machines set up in the exhibit hall so that conference goers could try it out for themselves.

Our new modeling diagrams, the logical datacenter, system, application, and class diagrams, really make building web services much easier. Not only are the code and the models synchronized, the logical datacenter diagram validates new web services against the deployment environment. The folks in the Whitehorse group, I mean, Visual Studio Team Architect group have really done a nice job.

Sunday, August 29, 2004

Microsoft Betas Agile Process

Microsoft is releasing an agile flavor of the forthcoming MSF V4.0. Download a sneak preview from this GotDotNet Workspaces site. [You need a Microsoft Passport to get in and you may need to be logged in to passport before you select the link to be successful].