If We Have a Problem, We’ll Find It. Early is Better. Still.

Let’s consider here a project with a significant problem we haven’t found. If the project’s product is to be a chair, maybe we have cut a leg too short. If the project’s product is software, maybe a function we designed with two parameters actually needs three (or reports answers in units different than a consuming function assumes it reports, maybe miles per hour instead of meters per second). This discussion is not about a misspelled word in a quick and informal email message, for example.

Do we get to choose between finding that problem or not? Well … (he he) … since our discussion is about significant problems, we’ll find it. And as one of the many corollaries to Murphy’s Law says, “If you have a problem, you’ll find that problem at the worst possible time.” (There’s something irresistibly pessimistic about that Law and all its Corollaries!)

You’ll find that problem just after you’ve spent lots of effort with the short chair leg in a lathe, getting sanded, and getting just the right finish (all of which was a waste of effort, of course, but you didn’t know that yet). It’ll happen just after you or your tester tell your executive that your code is 99 percent through testing, that the results look good, that you expect to complete ahead of schedule, and that the profits for this product are likely to start early. Or your customer will find the problem. (That would be embarrassing!) You’ll find that problem. It’ll hurt.

Let’s do something about it. And let’s focus now on creating software. Barry Boehm published once or twice (tongue-in-cheek) in a long and continuing software engineering career. In 1981, he wrote Software Engineering Economics, which contains the famous Constructive Cost Model (COCOMO) used for estimating the size and duration of software development efforts. It also contains (page 40) a graph showing the increasing cost to fix a problem introduced in requirements. The chart makes the point that if the problem costs roughly $15 to fix during requirements, it costs something like $50 in design, $100 during construction, $200 during development test, $500 during acceptance test, and $1,800 during operation. Many other sources of similar age make similar arguments and cite other cost studies. Their numbers vary, but let’s agree: cost to fix grows rapidly with time.

One message from those studies is: projects need a strong sense of urgency about finding problems we must fix because of the rapid increases in cost.

Another message is that a key question in managing a project is, “How much is the optimal spending now (in dollars, hours, process, whatever) to detect more problems earlier and get the greatest benefit from the current lower price of fixes?”

Sound good? Well … it certainly sounded good enough to form an orthodoxy in our professions. (Perhaps, anyway. It felt like that!)

From the current perspective, is there a problem?

Well … from today’s perspective, many of us would feel the data collection seems to presume use of the waterfall development model. Fewer projects use a waterfall model today.

And … many in our industry now have experience working projects without spending lots of time in review of past work. Many of us feel that the right answer to the question above is spending no time specifically looking for past problems.

And we achieve great results.

And our stakeholders love the new relationships with us as service providers.

(Well … not every time. New project models aren’t “the silver bullet”. And there are lots of other reasons projects don’t do as well as we want; many still need work.)

I refer, of course, to the development models advising us to strive for market agility (Scrum, Lean, Kanban, and Extreme Programming are commonly-cited examples). I intend to write more about these in future posts. For now, I’ll say: Much of the market has already moved one (or more) of these directions.

And what about the advice derived from the statistics Dr. Boehm cited? I’ll say projects need the same sense of urgency about finding errors; we’ll find problems differently than we most commonly thought about then. Projects using today’s agile models probably expect to discover those errors during their frequent interaction with customers (“early feedback”). And we expect to fix problems during the first iteration in which the customer wants us to fix them. And that advice sounds great … Why would anyone oppose?

And what about Dr. Boehm’s career after writing the book I mentioned? Well, in 1988, he published an often-cited description (info) of his “Spiral Model” of iterative software development. Both his works cited here influenced thought leaders who contributed to other models later collectively called “agile”. He is now an AIAA Fellow, an ACM Fellow, an IEEE Fellow, an INCOSE Fellow, and a member of the National Academy of Engineering.

He is one thought giant on whose shoulders we stand today. May we all learn …

//Later edit: Fixed a broken link.

They Don’t Know What They Want Until You Give Them Something Else

Steve Grandfield is a Blue Cross Blue Shield of Nebraska executive. (You might know the company as Nebraska Blue.) I heard him speak to Omaha Agile Development last week. Oh, my! How times have changed! Among other things, he said something very close to the title above, speaking about business customers.

I need to digress. (Sorry!) I want to send well-earned kudos to Steve, his company, and his company’s employees for the open house last week. It was an impressive display of talent, organizational change, and community interest. And as long as I’m throwing out kudos, Client Resources earned them for sponsoring and supporting the event. And Omaha Agile Development earned them for another in their continuing series of interesting and helpful presentations. (Can they possibly manage to do another good one next quarter? Join them to find out!) Well done, all around! And … back to the subject …

In prior days (“yesteryear”, in Garry-speak), the above title statement could well have been introduction to some boo-hoo about how tough it is to serve customers. “We toiling slaves in (fill in the blank with your favorite service organization; Steve talked last week about information technology, IT) have it so rough!”, the diatribe starts. “We’ll build anything our customers want. Wouldn’t it be nice if just once, they’d tell us what they want?! Well … they do … but they usually tell us late in the project when we’re panicked about meeting deadlines. And they tell us we have it all wrong. And they’re usually yelling at the time. Oh! Woe is us.”

Well … of course that boo-hoo-er spoke truth. They accurately described the environment from a partisan IT perspective (you picked up on the embedded “us vs. them” attitude, right?) They reflected IT frustration. Of course, there was similar frustration for the business folks. Many of them longed for the days when IT would be more affordable. (Funny thing, IT costs seem to be coming down faster than lots of people planned for … maybe that helps explain the timing of this subject. But I digress …) Many business folks saw IT as simultaneously skilled and inflexible; they wondered sometimes whether IT was more effort than its value.

Steve Grandfield’s message wasn’t the above; that would have been so … well … yesteryear. (Yes. It was fun expressing it that way!) His point was that none of us must feel trapped in the condition the boo-hoo-er describes. He points to market agility as a viable alternative goal. (Scrum, Lean, and Kanban are examples of advice to achieve agility. There are others.) He suggests the condition described as a prime motivation for changing.

Steve says that because the user cannot tell us what they want, we’ll do well to change our ways. I see him as suggesting pursuit of one of the common values among agile frameworks: get feedback early and often. That is, build a little working code. Then, inform the business user how the demonstration code is similar to the product you think they want (and how it’s different), and ask the business user what they think. Many business users, having described their ideal product, see this demonstration and can suddenly better describe the ideal. (That would be the subject title, right?!) The agile frameworks advocate using that condition to the service provider’s advantage. They argue that service providers would rather hear from business customers early than late that, “That’s good and I’d love it if you could also make it do …” And they argue that the earlier service providers hear that feedback, the more time they have time to adjust. The agile frameworks give service providers a better chance to deliver (really) the product that delights. “Delight” is not just an empty ideal any more.

I don’t recall that executives of yesteryear called for these processes. More and more of the market is adopting these ideas.