April 2008 - Posts

B*tch'n and Moen
23 April 08 05:50 AM | Earl Beede | 1 comment(s)

Steve McConnell put up a post on his lack of a real estimate for a child's fort and how that was related to a software project. I have a similar example of an agile bathroom remodel.

The Story

Our existing bathroom had a small problem. Water was leaking through cracks somewhere in the older tile, grout, or plumbing. Since repairing would require us to go to the studs to find any water damage, we decided to update the entire small bathroom.

The agile approach was to work out the details of the requirements as we were building the bathroom. We started with a planning meeting where we listed all the major goals/stories and preferences. We then planned to meet at the end of each day where I would be shown what the contractor completed that day and talk about what was planned for the next day. As I saw the completed work, I would give additional detail of what I wanted on the remaining work. My wife was home each day to act as the on-site customer.

So here are how the increments (simplified) went down:

  1. Tear out the existing tile, grout, and walls and determine water damage (limited, whew!).
    Check.
  2. Install new Moentrol pressure balancing valve and solder the copper piping to the shower head and water supply.
    Check.
  3. Install the (expensive) waterproof backer-board imported from Germany to create a watertight seal around the shower.
    Check.
  4. Install (medium priced) tile using mortar applied directly onto the imported waterproof backer-board and installing (expensive) decorative tiles and trim in the shower.
    Check.
  5. Install (expensive) epoxy grout that gets very hard but is waterproof and does not require sealing.
    Check.
  6. Install the (high priced) Moen Kingsley faucet.
    WHOA!

It should have looked a bit like this.

T3111

Notice there is a little bit of a gap between the handle and the escutcheon (big silver plate). Probably a quarter of an inch or less.

This is what mine looks like (it really is silver, though, like the previous picture).

MyMoen

Notice how much larger the gap between the handle and the escutcheon is? When measured, it is over half an inch! Every time I see it I think, "Hey, I need to push this thing on the rest of the way!"

You should see it when it is pulled out to the 'on' position; over an inch. It looks like one of those long needles on a seismograph. Maybe not a bad idea for where I live in the earthquake prone Pacific Northwest. I will know about every tremor in the shower.

So what are my choices as the customer at this point? My choices are one of two:

  • OPTION A: Move the Moentrol valve further back into the wall. To do that the contractor would need to grind out the (expensive) epoxy grout, chip out the (medium priced) tiles and (expensive) decorative tiles & trim, and cut out any of the (expensive) imported backer-board that wasn't ripped out with the tile and mortar removal. We might not need to unsolder the copper piping. Once exposed, we could then move the valve further back into the wall. After that, we would need to reinstall new (insert cost here) backer-board, tile, decorative tile & trim, and epoxy grout. Please note that this would increase the cost and schedule of the initial repair project by at least 60%. Please also note that given the patch job in the backer-board, tile, and grout that a leak into the wall is more likely—just what we were trying to fix.
  • OPTION B: Learn to enjoy my unanticipated Moentrol Washcloth Holder™ feature.

The Project Analogy

While I know of many successful agile projects, I also hear something like the following phrase way too many times. It goes, "We were working an successful agile project when it was suddenly canceled due to outside factors." Those factors range from mergers to business changes. But, I ask myself, if these projects were delivering value, why where they canceled? Sure, some business changes would lower value but canceling a project is pretty rare, even in non-agile settings that are NOT delivering any value at the moment. So why?

My guess is that the customer received a Moentrol Washcloth Holder.

Sure, the functionality is absolutely correct. The faucet functions just like a faucet should. The story is satisfied. But the solution just isn't right and it isn't what was expected. Turns out that this expectation about the solution concerns non-functional "quality" requirements, not the functional requirement well captured by the story. Further, it is a horrid truth that non-functional requirements are designed into the solution, not coded in at the last moment. Our development approach didn't deal well with this particular non-functional requirement. Our emerging design was not easy to change. I did not see the design flaw coming.

Few development approaches (Evo exception noted) deal well with non-functional requirements. Software development has a functionality bias.

Faced with a Moentrol Washcloth Holder, the customer's perception of value plummets. Costs have not changed, functionality has not changed, but the desire to defend and promote the project has suffered a tragic blow. The excitement is gone and any other interesting work sounds better than another Moentrol Washcloth Holder.

The Reflection

Could we have foreseen the non-functional requirements failure? Where did the failure stem from so we can prevent it from happening again? I called the Moen help line to find out about the expected gap between the faucet handle and the escutcheon. Their representative said that he has heard that the average gap is about 1/2 inch.

"But," I protested, "it looks really stupid. Like it is not all the way on."

"You need to clear the back plate [escutcheon]," said the rep. Now, I only play a mechanical engineer on TV but I figure two chrome covered pieces of metal embedded in a wall will not expand more than 1/32 of an inch. I really don't need 1/2" let alone the 5/8" I got. Bad valve design on Moen's part.

That could be fixed with good instructions about how deep to put the valve in the wall. The detail of the Moentrol valve installation instructions that is appropriate to the discussion looks like this

image 

My contractor tells me that it means that if you have a thin wall (like a inserted fiberglass shell) to push the valve back behind the wall. If you have a more normal wall like mine, make the valve flush with the outer wall. To me, it doesn't talk about the critical information at all: the stem length. Bad installation instructions on Moen's part as well.

All this could be corrected by a knowledgeable contractor. Knowing that the valve design creates a long stem and knowing that the installation instructions do not reflect that the stem is longer in this Moen product than in past Moen products, they could have compensated. In fact, one of the contractor's employees stated after the fact to the contractor something to the effect of, "Remember the last one we put in, how it stuck out this far?" Bad implementation by the contractor.

Finally, as customers, we had an unpleasant encounter with the contractor's choice of fixture supplier so we decided to purchase this particular faucet based more on the sink faucet than the shower. That is, we never saw a prototype of the faucet shower. Bad due diligence on my part.

In reflection, the contractor could have raised a risk based on past experience and called for a spike. I, also, could have asked for a spike to check out the shower faucet since I knew I hadn't seen it anyplace except the manufacturer's web site.

We could have done a better job a risk management by attacking those non-functional requirements through prototypes (spikes). We needed more up-front planning. It may not sound as agile as many like but, there you have it.

So, on the next job I will hopefully apply the lessons learned. That is, if I don't cancel for fear of another Moentrol Washcloth Holder.

Filed under: , , ,
Giving Up
03 April 08 07:12 PM | Earl Beede | 1 comment(s)

When is the right time to give up on a project, a design approach, or a requirement? What factors do you consider in coming to the decision that it is not in the organization's best interest to continue forward with the current approach?

I know that the economically oriented folks will suggest that we look at the net present value discounted over the useful life period minus the initial capitalization and number of pizzas ordered per developer. Sure, that is a fine rational way to do it. However, it has the fatal flaw of relying on human beings to generate the numbers and eat the pizza. In my years of playing with numbers, my conclusion is that the world "playing" is the correct choice. You can come up with just about any result you want.

The economic approach also misses the emotional side of the equation. The project was needed to drive the revenue (or cut the costs) necessary to meet some commitment made to the organization in the annual goal setting exercise. If the project does not deliver, some director or VP will not meet their numbers and that director or VP will look bad. (If we talk about not getting a bonus, then we are back at the fatal flaw of the economic model.) People do not like to look bad so they hang onto the project, the design approach, or the requirement long past its pull date. At which point, they still won't meet their numbers but then the director or VP can blame the poor developer for not living up to the developer's commitment. That the commitment was extracted by force is quickly forgotten.

Don't forget the stigma of being labeled as "negative". If we even suggest that the current approach is not working, the goons from the Corporate Office of Positive Thinking come to pay us a visit. They encourage us to try harder, to work through the challenges, to be a team member and give 1,837% to the effort. Any thing shy of 1,837% is a defeatist attitude and you should probably rethink your career choice.

There often is a lot of pressure not to give up.

So how do you finally make the decision?

The most common answer my exhaustive research (asked a couple of people) has uncovered is (drum roll please) fatigue. As in I am too tired to keep trying.

Case is point is my latest decision to give up on compact fluorescent lighting (CFLs). Yes, I know CFLs are god's gift to lighting and I must be an environmentally insensitive global warming jerk for stopping my use of CFLs. However, I have reached my fatigue point with them. You see, I have this really bad habit of turning of lights when I leave the room (blame my father) and CFLs hate that. They don't like turning on and off. Every time you turn them on and off, they shorten their life span.

So, I found myself leaving lights on (and having the echo of my father yelling at me) or end up paying more for a light bulb that a) didn't last as long as a incandescent and b) put out less light. On top of that, I have a garage full of the damn things waiting to go to the hazardous waste site since you can't throw them away.

I got tired of messing with them so I gave up. Is this the most rational way of making the choice? Maybe not. However, I do think it is the most common way, whether CFLs or software projects. I wish there were a better way but this is the one that seems to work.

Filed under: ,