It's All Relative

A friend of mine was recently describing his workplace to me, and I couldn't help but evaluate it (in my head) as if it were supposed to be an Agile environment (which it isn't). I realize that that's a bit of a strange reaction to have, but it happened nonetheless.

So here's a thumbnail sketch of what I envisioned as I heard more about the office in question:

1. Leadership style - From what I could tell, it sounded like a very Command & Control setup, although I was interpreting from just one person's comments. The managers keep a very tight grip on all of the decision-making, to the degree that the expression "micro management" kept coming to mind as he related some of the day-to-day occurrences. In his view, this level of hands-on guidance was completely normal and expected from management, but I marveled at how unaccustomed to that style I'd become in recent years.
2. Trust - People in the office are all on fairly short leashes in terms of working hours, as one example of where trust is lacking. Even back in my pre-Agile days as a manager, I think I established a fairly easy-going attitude when it came to things like people needing to shift their hours around or take time off for personal stuff. Therefore it was quite eye-opening to hear about a white collar shop, in 2009, that still operates under very rigid rules in that regard. When I asked about it, I was told that "someone in the past had abused [flex time], and so now they don't allow that sort of thing." Rather than simply penalizing the person in question and extending trust to the rest, I guess the decision was made not to trust anyone with that kind of latitude.
3. Transparency - The funniest example I heard involved some data that was being gathered about productivity within the group. At first I was excited to hear that metrics were being used, but then it turned out that the information wasn't going to be shared with the "rank and file" because of fears that they'd adjust their behaviour (in the wrong direction) if they saw the data! That was just mind-blowing to me, but it probably shouldn't have been. After all, transparency is certainly not the norm, no matter how much we might want it to be.
   
4. Empowerment - Because it's always been a favourite topic of mine, I tried to ask the sort of questions that would give me some sense of how empowered employees were at this company. The impression I got was that some of the leaders play what I like to refer to as "the false empowerment game", which goes as follows: I tell you to do something but I don't tell you how or give you many details. When you proceed to do what you think I wanted done, then I look at the results and say, "That's not right. I want it to be more like this." After a few more iterations like that, we finally end up with the correct product. (So, in one sense at least, they're doing iterative development!) The problem with that approach is that it wastes a lot of time and teaches the staff not to make decisions.

Now, as I say: this isn't an Agile office that I was hearing about, so there's no reason why they should be expected to live up to Agile principles. And yet I couldn't help but wonder just how much better they might be doing if it were, and they were.

The Latest Lecture

Today I did my third iteration of the "Introduction to Agile" university lecture for second year Computer Science students. The class size was around 30 this morning (out of a possible 38), which was bigger than it's been in the past. I'd love to chalk that growth up to the AgileMan reputation spreading across campus and bringing them in from far and wide, but I think it's actually just a larger enrollment this time around.

Since my material tends to be the same each semester, what distinguishes the different sessions are the questions posed by each group. Today, one student asked whether Agile only worked for smaller companies, as it seemed to him that it wouldn't scale well. I explained that it had been fairly common for people to assume Agile wouldn't work in larger companies, but that books had then started to appear that provided insight and guidance on how to scale the practices without losing the principles. Because time was limited, I didn't go into any of the examples, such as the Scrum of Scrums (or even Scrum of Scrum of Scrums) concept to facilitate communication between teams, or Communities of Practice to share learning and discoveries. But I thought it was a good question and showed that the young man asking it had been thinking about what he'd been hearing.

Another question was, "With Agile, do you see more instances of burn out?" As soon as this was raised, I realized that nowhere in my slides do I mention the concept of "sustainable pace." I'll have to correct that for future lectures, but in the meantime I explained what's meant by that term. Then I described how you have to reinforce that principle, in both words and actions, and that failure to do so can quickly lead you down the path to an endless series of death marches.

I was also asked what tools are available to use if you decide to go Agile (I rattled off a few, and mentioned that since Nature abhors a vacuum, there were new ones showing up on the market all the time) and what sort of projects would be better suited for Waterfall (a question I've gotten before, and to which I always offer up "heavily-contractual, government and/or highly-specified work where the customer doesn't typically change their mind midstream").

As happened with the third year, 3-hour lecture last November, this one ran out of time before we'd exhausted all of the questions. That's always a much better feeling than what's occurred with previous incarnations of this second year course: few or no questions and a palpable sense of relief from the attendees that it's over! I'm not sure what to attribute the difference to this time around, but it just seemed to flow better all around.

What Can We Learn From Video Games?

When looking for insights into how we can all work together more effectively, there are worse places you could go than into the online environment of video games.

The sorts of games that I play, at least, have many of the same attributes that we value in the best workplaces:

• a focus on teamwork makes a difference - many squad-based setups only reward the individual players with experience points and movement up the ranks if they work together toward team-oriented goals; lone wolf tactics in team games are generally unsuccessful, and sometimes even penalized
• adaptability is a must - while a select few may be naturally gifted at the art of gaming - or software creation! - most of us discover quite quickly that we can only achieve respectable results if we adapt to each new environment; adopting an attitude of "that's just the way I am!" rarely works very well in online competition, just as it's severely limiting in Life
• clear goals can work wonders - there are few things quite as frustrating as not understanding what you're trying to achieve, and video games are becoming increasingly aware of that fact; you may be informed of your objective(s) in any number of ways (icons on a map, voice-over instructions, or even a small on-screen display of the current score) but the point is to keep everyone's eyes on the prize... which is equally sage advice for the workplace, as well!
• metrics and other forms of feedback are powerful - just as important as having goals is the understanding that reporting results will affect how people behave; one of the ways video game companies capitalize on this is by providing lots of statistics to their players; if you know that you're doing especially well with one type of weapon, for example, that may inspire you to use it even more and try to rise to the very top of the leader boards in that category; conversely, you might decide to direct your energy toward an area where you've discovered that you're below average, now that you have that data in front of you; in all cases, having more information empowers people in ways that ignorance never will
• leadership always reveals itself - if you've ever played online and watched a really good player take over a game, making the entire team better through a combination of outstanding strategy and technique, only to later discover that you were following the masterful guidance of a 12 year old kid, then you know that leaders come in all shapes and sizes; those who can, lead; those who can't, need to learn how to follow... and video games often make that distinction readily apparent in ways that questionable promotions and titles at the office seek to obscure

While admittedly somewhat tongue-in-cheek, I still hope that this post will nevertheless make all of us consider just what might be gleaned from even the most unlikely of sources... including video games!

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.