Risk Assessment Is An Underappreciated Talent

Any project managers out there, upon encountering this blog post, are probably looking at the title and saying, "Yeah! You better believe it!" In many software development organizations (perhaps most of them), it officially falls to those in project management to worry about risk. In reality, though, risk identification and mitigation are two concepts that every one of the project participants should care deeply about.

To draw on a current real world example, look at the state of the financial industry in America right now. No one in their right mind would describe it as anything less than disastrous, no matter how much people may disagree on the exact root cause. One of the main contributors to the meltdown, we've been told many times, was unbridled optimism. Whether it was home owners taking out mortgages that they couldn't afford (but all of whom believed that they could), real estate speculators assuming that housing prices could only continue to go up, credit businesses refusing to consider the consequences of a market downturn, or the public in general failing to set aside much in the way of "rainy day savings," the result was the same: once the first domino fell, all of the rest were lined up in a perfect, catastrophic pattern behind it. In other words, a lot of folks misinterpreted a variety of "best case outcomes" as being virtual certainties.

In the world of software, we face a very similar problem. When we create a plan - whether it's a traditional Microsoft Project plan for Waterfall environments or an Iteration plan for an Agile team - I've too often seen what I can only describe as that self-same unbridled optimism. In one way, that's a commendable attribute: after all, it's indicative of a "can do" attitude that's much preferable to a bunch of nay-sayers who won't even try, for fear of failing. But it still has to be tempered with reality. At the very least, any group involved in this sort of planning activity has to spend some time discussing what might reasonably go wrong, and what the impact(s) for each would be.

That's the identification part of the equation, and I'd say (from my own experience) that programmers in general tend to grade somewhere around a C- at that. You'll get some who are really good at it, and others who apparently can't see anything at all in front of them except the Yellow Brick Road that leads directly to Oz. Team members with a testing background or responsibility are usually better at this, perhaps because their stock and trade is stuff not working the way it's supposed to. I'd say the average test-inclined person maybe scores a B- at risk identification, although, again, you'll certainly get all sorts of results. Some testers, for example, only think in terms of bugs in the code, rather than considering "bigger picture" hazards like environmental issues, requirement ambiguity or dependency failures.

When you bring that programming perspective together with the testing POV - either in a meeting, or as Agile tends to do, in one person or a close-knit team - I think the discussions often provide some very good risk identification. The two views feed off of each other, and pretty soon you'll hear some very creative ideas of "what could go wrong." This is more of a refreshingly-effective B+ effort, if you can make it happen. There can almost be a gallows humour aspect to those talks that may cause the unseasoned project manager/stakeholder to run for the Pepto-Bismol! (So, yeah, it can be fun!)

For risk mitigation, though, I think the software world in general really lets our PM friends down. I'd even go so far as to say that we probably earn a solid F in this particular area (or perhaps it's simply an "Incomplete"). In part, the bad performance here stems from the fact that mitigation is often as dependent on the corporate culture as it is on anything else. As an example, consider the classic case of an external dependency not being met. In some companies, such an event would be regarded as reason enough (some might say "excuse") for the greater initiative to fail. Therefore, there might be little stomach for planning any mitigative actions for that possibility, as the blame would be laid squarely at the feet of the non-deliverer. End of story. But in other environments, there can exist expectations - spoken or otherwise - that those involved in the local project can somehow work around unfulfilled external deliverables. Those two scenarios are very different, and it behooves everyone on the project to know which type they operate within. And that's something that makes this whole "what do we if this risk becomes reality?" question hard to answer, especially when you consider the unspoken expectations that often go along with the handling of these risks.

Another challenge to good risk mitigation is that old favourite of mine: empowerment. If a company has a consistent and well-understood empowerment model, then it's easier for a group of programmers/testers/product reps to tackle what to do about each potential hazard. In a top-down model, you may be able to simply kick the problems upward, and comfort yourself in the knowledge that your job is to identify the risks and then escalate them. Again: end of story. Where teams are more empowered than that, then they'll probably look for creative solutions that may involve spending money (buy additional hardware, set up network redundancies, increase bandwidth) or moving human resources around (get temporary expertise from elsewhere, increase headcount on the project), with some reasonable assumption that their time wasn't wasted in considering those options. Where the empowerment model is muddy - maybe one type gets lip service paid to it but another is found in practice - then the job of risk mitigation becomes that much more difficult.

As someone who worries a lot about risk - maybe too much, according to my wife! - I can't help but wish that it got more consideration in the minds of others. When things are going well, there's a natural tendency to expect that delightful state to continue forever. But it's our ability to imagine just what might come along and turn all of our plans to mush that gives us an advantage... if we remember to use it! Otherwise, we end up with situations like the cratering American financial sector.

How Do Incentives Really Work?

In many of the write-ups of the financial woes gripping the world right now, it's pretty clear that certain incentive programs were put into place over the past decade without any clear understanding of what their logical outcomes would be. For example, people in the U.S. were encouraged in many different ways to get into the housing market: through income tax breaks relating to their mortgage interest, through low interest rates in general as well as - in some cases - even lower start up rates (deferring the higher rates until later in the life of the loan), and through changes in the banking laws, intended to help lower income families get into their first homes. All of those forces acted at cross purposes to set up a scenario where lots of folks would have mortgages that they couldn't really afford, which was at least one of the catalysts for the larger financial mess that we're in. And no matter how harshly one thinks of the last couple of administrations in the U.S., no one in their right mind would suggest that what we see around us today was the goal of those actions!

So why is it so hard to get incentives to work out in the way that you intended? Part of it, I think, is that you need to have all of the players aligned with the same goal. Going back to the sub-prime lending fiasco, there was a clear disconnect between the objectives of those involved. Many of the financial companies doing the lending, for example, didn't care whether or not the recipients of the mortgages stayed in their homes (they'd already repackaged the debt and sold it off to others to worry about) as their focus, in the form of compensation, was on volume, not stability. The recipients of the loans wanted one of two things (or possibly both): a long-awaited entry into the ranks of home owners, and/or an investment that they believed would net quick profit. Finally, many of the original statutory changes were aimed, in one way or another, at getting citizens who had sub-standard credit rankings but were otherwise viable mortgage holders their own slice of the American Dream. There's very little alignment there. More than that: the notion of "quantity over quality" (on the part of the lenders) was often completely at odds with the goal of housing viable mortgage-holders. Hence the unfortunate results.

In a software organization, the stakes are usually a little less earth-shattering (thank goodness!). A typical case might be a yearly or quarterly bonus program in which the portion realized by each employee is dependent upon how they themselves, their team, their department or the company in general (or any combination, thereof) does against certain objectives. That sort of thing rarely causes the worst case outcome of clashing goals and carnage. Instead, the most common result seems to be a relatively benign disconnect, in that the average employee may feel that he or she has little influence over some of the broader metrics. In that case, the setup has simply been ineffective, rather than counter-effective (whew!).

Better programs and initiatives, however, actually manage to inspire results that might not have come about without their inclusion. While admittedly small potatoes, I've seen and heard of nice results coming from something as simple as establishing rewards for suggestions that end up saving the company money. It becomes less about the money itself - is anyone really that motivated by a $20 gift certificate anymore? - and more about the recognition, the feeling of accomplishment, and the confidence that comes from believing that you're operating within a system that values improvements. It can actually create a cultural paradigm shift, away from "Why bother complaining, since nothing ever comes of it?" and toward "If something's broken, let's fix it!" And that can make a world of difference, although it may happen so gradually as to slide under most peoples' radar.

I think a lot of incentive programs never come into being because there's a decision made, at some point along the way, that it'll either be too expensive, or too susceptible to gaming. The cost issue is always a thorny one, and perhaps the only way to deal with it is to budget a certain amount, broadcast that fact, and then see how it goes. If you end up running out of money before you run out of time (or ideas), then either it was a success and you should attempt to increase your budget for the next period, or you got very little value out of it and it's time to re-tool. Either way, you can adjust and go forward.

The gaming concern is a different problem to solve. First, I came to the conclusion years ago that there will always be someone in any group of ten or more (just to pick an arbitrary number) who will attempt to get something for nothing. And that's what gaming is, after all. The person who hears, "Our bonus is tied to how many test cases we write because management wants our test coverage to improve" and thinks, "I bet I can make more money if I make all of my test cases really trivial and small" is hoping to get something (a bigger bonus) for nothing (doing no work that will actually improve his company's situation). But the number of employees who react that way will, generally-speaking, be inversely proportional to the quality, relevance and clarity of the goal. Most people, given the proverbial "SMART objective" (specific, measurable, attainable, realistic and timely), will enthusiastically put their back into it and work toward it... especially when there's money on the line. Therefore, it seems to me that time is better spent by those in leadership establishing the goals, including the metrics and rewards, rather than worrying about what gaming may occur. Even if a few bad apples work against the spirit of the program, the vast majority will produce more than enough of the good stuff to overshadow them. And eventually peer pressure, as well as the sense of accomplishment coming off of those really doing the work, will transform the culture into something in which gaming isn't abided at any level.

Of course, as always, it's easier said than done. But that should never stop us from trying!

Where's The Happy Medium Between Gold-Plating And Shoddy Work?

I think sometimes the line between "not good enough" and "better than it needs to be" is about the width of a razor blade (not that I know all that much about razors!). And that slim of a margin for error is not a very easy target to hit, especially amidst the chaos, pressure and distractions of most software projects. So what can we do to make the situation better?

Well, first I think that we need to examine what's really happening whenever accusations of "gold-plating" come up. I've seen it often enough in the past 22 years to at least have some ideas on it by this point in my career. The most common culprit always seems to be time, in the sense of there never being enough of it. When a customer, or project manager, or really any stakeholder with their ass on the line has their eye on the calendar, "finishing touches" can quite easily take on the appearance of "make work projects" or "endless tweaking" (and I don't mean the kind that requires amphetamines!).

To appreciate that perspective, just imagine that you've gone to pick up your car after a repair. You're in a hurry because someone's waiting for you and you told them that you'd be there by now, only to take longer than expected to get to the garage and then find out that the car's almost-but-not-quite ready. You then catch a glimpse of the mechanic busily doing what looks for all the world to you like a polishing job on your hubcaps! Of course you'd be frustrated at that scene, because as far as you're concerned you'd much rather get where you need to be right now with dirty hubcaps than arrive there later with 'caps that look brand new. But what if what was really going on was that the mechanic was checking out your tire pressure and using a rag to clear the tire well enough that he could read what the pressure should be? Most people would agree that having your tires checked is hardly "gold-plating," but you may not even know that that's what is actually happening from your vantage point. And on a more relaxed schedule, you'd simply trust that the mechanic knows what he's doing rather than jumping to any unfortunate conclusions. Start the clock ticking, though, and that whole willingness to extend trust may go right out the window... unless we make a conscious effort to be aware of that trap, and avoid it.

Now, that first point assumes that it's a simple lack of understanding that's creating the conflict. The software developer, in that case, is engaged in some activity that he or she has every reason to believe is required, in their expert opinion; meanwhile someone less involved leaps to the wrong conclusion about it being unnecessary. That's certainly not going to be the only scenario that can result in "gold-plating" charges being thrown around, though. Another possible cause is that there actually is work being done that is above and beyond what's needed to complete the job satisfactorily. So how do developers know when they've reached "good enough" with a piece of functionality?

One obvious way to answer that question is to ask another one: "What's the likely result if I don't do this next bit of work?" If that query can be posed and subsequently answered honestly, then I think we'd have far fewer confrontations of the sort discussed in this blog post. Most of the time, though, I suspect the question's not even being asked; and of those times when it is, then all too often the answer offered up is at least somewhat disingenuous. Why would a developer not honestly answer it? Because they may have an agenda (hidden or otherwise) that's not necessarily related to customer satisfaction. Some examples would be:

• "This code is too hard to work with unless I change it to look like what I'm used to."
• "The customer might ask for this functionality in the future so I need to put it in now."
• "I've thought of a case that will probably never happen, but if it did this code might possibly break so I'd better rewrite it."

That's not to say that any of those responses are categorically bad; just that they might not be reason enough to dictate that something's not ready, and therefore delay a release. And even a whiff of that sort of thing can cause the cries of "Gold-plating!" to go out.

So there we have two of the many ways in which this unfortunate situation can arise. To guard against them requires greater transparency, communication and honesty than we might naturally demonstrate if we just went about our business with our heads stuck in the sand. Living up that higher standard is a lot to ask of us all, to be sure; but as skilled professionals who take pride in our work, we can do it... can't we?

The Story Of My Life

Ron Jeffries, one of the better known authorities on eXtreme Programming (XP), recently posted an article on his XP blog that really resonated with me. He calls out, for what is certainly not the first time, the idiocy of adopting an Agile methodology without doing the whole thing and then faulting Agile when it doesn't work out for you. Readers of my 2nd AgileMan book will recognize that I witnessed that first-hand, and the results were just as Jeffries describes them.

The following paragraph, in particular, paints a compelling portrait:

"Well, my dear little children, I’ve got bad news for you. It is your precious context that is holding you back. It is your C-level Exeuctives and high-level managers who can’t delegate real responsibility and authority to their people. It is your product people who are too busy to explain what really needs to be done. It is your facilities people who can’t make a workspace fit to work in. It is your programmers who won’t learn the techniques necessary to succeed. It is your managers and product owners who keep increasing pressure until any focus on quality is driven out of the project."

Setting aside the condescending tone, it all sounds eerily familiar. In a funny way, I guess it's sort of comforting to know that what we went through was far from unique in the annals of Agile. But only sort of.