Debunking Some Start-up & Software Myths

I saw a great article by Tim Ferriss quoting Rob Mee of Pivotal Labs thanks to someone I follow on Twitter, and thought I should mention it here. It's rare that I read an article on a topic like this and agree with it 100%, but it happened in this case. I encourage you to check out the post itself, but in order to whet your appetite, here are the 7 Myths he describes:

1. You have to hire "ninjas."
2. Programmers need to work in quiet, without interruption.
3. Start-ups run hot, so we're just gonna have to burn everyone out.
4. Looming deadlines necessitate shortcuts.
5. Developers should take ownership of their code.
6. You need a quirky hiring process.
7. Specialization is essential.

As I say, it's a very good read and excellent food for thought!

What Motivates Creative Thinking?

A friend and former co-worker of mine pointed me in the direction of this video of Dan Pink speaking at this year's TED (Technology, Entertainment, Design) Talks, in which Mr Pink (not to be confused with the character from Reservoir Dogs!) provides some evidence-based thoughts on motivating creative thinking. I encourage everyone to go check it out.

After watching it, I started thinking about my own experiences in the software industry. Pink's Autonomy-Mastery-Purpose summation certainly matches what I've seen in the best of scenarios. And, of course, those three characteristics mesh perfectly with the principles of self-organization, continuous learning and prioritized backlog that Agile are built upon.

From what I've seen, it's definitely no easy feat to create and sustain a culture in which all three of them are:

• valued in word,
• valued in deed,
• committed to at all levels of the organization, and
• not sacrificed in the name of "expedience" or "meeting a schedule".

Some simple examples of where I've seen them compromised would be in management clawing back control from teams whenever they're unhappy with the outcomes, pressure being applied to produce substandard work rather than allowing a maintainable design to be implemented, and failures to provide a consistent vision or message for a project or product. Those are all leadership shortcomings, but you can also see it at the developer and tester level when individuals on teams refuse to take responsibility for their mistakes (the "downside" of autonomy), become lazy about following through with Retrospectives, communities of practice or just general inspection-and-adaptation, or give up on their principles at the first sign of resistance. Like I say: it's much easier to fail at autonomy, mastery and purpose than it is to succeed.

I don't believe that those who fall down in the attempt, however, realize just how much they're losing by not trying harder. For one thing, you only get so many chances to introduce that kind of culture, after which you lose your credibility for a long time to come. Even when we were introducing Agile to our company in 2006, I met considerable resistance from folks who'd been there long enough to remember previous attempts at reorganization and empowerment, and were thus doubly skeptical of the results. There's also the flawed "we can't afford the schedule hit" aspect to failure in this area. One executive I came into contact with was always saying, "We'd love to build that kind of culture but there just isn't the time." Ironically, of course, whatever deadline was being worked feverishly toward would be missed (and missed and missed) anyway because of all the problems being ignored, meaning that the much-needed improvements were put off for no reason in the end. It becomes a vicious circle that's awfully hard to break out of.

The most creative work I've seen has always come from those who are given the latitude to wander down many paths, the tools and training that they themselves believe they need, and a general - rather than specific - direction to follow (so, "what", but not "how"). In some companies, I suppose, that sort of revolutionary work may not even be necessary or desired. But for the rest of the IT world, leaders do themselves and their organization a terrible disservice whenever they believe, as Dan Pink illustrates so capably, that they can simply dangle a reward in front of their heavily-supervised employees' eyes at random points in time and achieve greatness. When you do that, you end up with the most unimaginative of solutions, like a candle stuck to a wall with pushpins, dripping wax down onto your table.

The Relationship Between Trust And Leadership

An article I was reading this morning got me thinking about how the quality of leadership within an organization relates to the level of trust that you'll find there. I'm not sure that it's a perfect model that I've come up with, but it seems to fit most of the scenarios that I've observed in my travels.

Basically, the relationship seems to be quite simple: the better the leadership, the more trust exists. This is one of those situations where you can perceive the effect (trusting and trustworthy players vs distrust between parties) in direct proportion to the causal factor (effective vs dysfunctional leadership), but it also can work in the opposite direction at times. I dedicated an entire chapter to this in my second AgileMan book (Issue # 46: Who Do You Trust?) but I think that I was still too close to the proceedings at that point to really see just how tightly tied together the two things were.

For example, a leader may start off willing to extend a great deal of trust out to his or her employees, only to feel "betrayed" by them if the same good faith isn't extended back. Imagine a team promising to complete some vital feature, giving "thumbs up" reports on it throughout the Iteration, and then falling well short of the goal in the end. That kind of result can cause a well-intentioned leader to change gears and begin compromising principles: becoming more of a micromanager, reducing the amount of freedom allowed to the team, or just generally dictating more of "how" on future work. In one way, I suppose, we could still characterize that unhappy outcome as being the result of poor leadership. After all, in an Agile environment at least, we expect leadership to emerge within teams, as well. So in my sample scenario, the team that "green-shifted" their situation right up until the end failed to demonstrate the type of maturity, honesty and transparency that we'd expect from a well-performing Agile group.

Just as likely, though, it's the manager or executive who failed to fulfill his or her responsibilities that leads to the breakdown. I certainly saw numerous instances of that in my role as Agile Manager, and in each case the result was a weakening of the bonds of trust between the organizational layers of the corporate pyramid. If a Product Manager promises to be available but isn't; if an executive fails to provide a vision of where the company is going; if team members are blamed for dropped balls that were actually someone else's responsibility... each of these qualities of poor leadership eat away at the foundation of trust within the organization. And that's not just a bad thing on paper, either.

Among the many ways in which a lack of trust hurts an organization, I saw:

• time wasted as people (in both groups) sat around and bitched about how they couldn't trust the other group any longer
• wasteful defensive measures planned out and enacted as ways to guard against the possibility of being let down or thrown under the bus by the other group
• the baggage of past betrayals brought up, again and again, in almost every new interaction, making it nearly impossible to ever achieve a fresh start
• a complete reversal of the empowerment model that Agile depends on, as more and more of the conversations would devolve into "contract negotiation" as each side would want detailed recordings of exactly what was discussed in order to fend off future allegations of failure
• a very unhealthy "us vs them" attitude that benefited no one and drove morale to continually lower levels everywhere

I suspect that superior leadership can overcome many of these threats, but it's definitely not easy. Each time I was a Feature Lead, for example, I felt the unmistakable pull of distrust exerted between me and my new team. They weren't sure that I wasn't there to take over and remove their decision-making powers, and I was never quite confident (at first, anyway) that they would do what it takes to get the job done. I'm pretty sure that's a typical place to start, and it's no wonder that so many people in leadership roles find it impossible to resist that gravitational force that's urging them back to familiar, top-down approaches.

What that tells us, of course, is that choosing your leaders in an Agile environment is all the more important, and not something that should necessarily be done by the same old rules of the past. If you make that mistake, chances are you'll be dealing with trust issues for years to come.

Why Transparency Matters

Sometimes it astounds me just how much transparency exists in the world today, and how much benefit we derive from it. In some cases, it's the incredible access to information that we have, mostly thanks to the Internet, while in others, it's simply how willing people are to share what they're doing.

As examples of the former, I started making a mental this morning of some of the data that's now almost literally "at my fingertips" that would have, even a decade or so ago, been at least a phone call or trip somewhere away:

• animated radar images of the current precipitation patterns in my locale, so that I can plan my biking forays accordingly
• real-time, up-to-the-minute sports scores, including details like who's pitching, who assisted on what goals, and how many shots have been taken
• specifications for devices like pool heaters and DVD players that you may have long since lost the paper copies of
• forms, as well as forums, related to topics like Canadian Income Tax, immigration policy and travel destinations, just to name a few
• dictionary and encyclopedia content enabling anyone to write a factual, typo-free essay (or blog post) without having to even get up out of their chair
• transit system schedules so that you know exactly when to be where to catch what (bus/train/plane)
• and thousands and thousands more

Similarly, we're able to get much greater insight into, say, the creative process behind a television show, movie or comic book than we ever could in the past, thanks to creative folks who "put it all out there" for the world to see. Not that long ago, much of that would have been closely-guarded secrets, or simply considered too pedestrian to warrant the time to write it down and the cost to publish it. Now, however, it's just a few clicks away.

So what does any of this have to do with Agile, or software development in general? Well, I think that we're realizing many of the benefits of transparency in the 21st century (as touched on above), but that doesn't necessarily always get applied to how we run our development projects. In an Agile culture, we strive for transparency in some very big ways - Burndown Charts, strictly-prioritized Product Backlogs, Retrospectives - all of which are important and positive. If you compare that to a more traditional (Waterfall-style) software project, though, you can see that the same degree of transparency is seldom achieved there. Team members may seek to hide some of what they're doing out of fear that the work won't be approved if the bosses find out about it. Project coordinators may talk about, or even hope for some sort of post-mortem to be held after the product finally ships, but rarely do those mythical meetings actually happen. Status reports all too often end up being "green-shifted" by those responsible for providing the data, in order to keep the alarm bells from sounding early on. These are all instances where the lack of transparency hurts the success of the project.

Even in an Agile environment, however, there can still sometimes be a resistance to openness. I certainly encountered many situations in my two years as Agile Manager that spoke to this point. Whether it be shutting down conversations or blogs that are bringing to light unsavoury failings among management, or a reluctance to share with others the challenges that are being encountered (because it might be used against you later), it's no easy task to adopt a culture of transparency. Politics can get in the way, as can pride, fear and an exaggerated sense of self-preservation. None of those are trivial obstacles to overcome.

Unfortunately, in virtually every case this tendency toward hiding facts ends up doing more harm than good. Decisions end up being made based on faulty data, morale problems develop thanks to a cloak of secrecy that seems to always inspire conspiracy theories much worse than the reality of the situation, and people waste time going through hoops trying to find "the person with the answer." When I think about how efficiently I can use my time today, thanks to the wealth of information available to me, compared to what life was like when I first started working... it's like night and day. And that's because, given quick access to the necessary data, it's always easier to make a reasonable, informed decision. That perspective sometimes gets lost in the heat of the office battles, though. Those of us in the Information Technology industry need to remember that, as we go about our day-to-day business of cranking out top-notch software products, information is king. And the king belongs to everyone.

So if you're reading this from your desk at work right now, ask yourself: what bit of data are you holding on to right now, that would better serve the company if it were shared? Don't betray any confidences (personal or professional), but rather look for something that you've simply been lax in getting out there, or that you know would help someone else if you made the effort to tell them about it. Sometimes that's all it takes.

How Can Productivity Really Be Increased?

As our current Recession continues to wreak havoc across the employment ranks, one topic that we'll all surely hear more of is "increasing productivity." It's the conjoined twin of "reducing costs," after all, which has already proven to be a popular refrain since last Fall. Once a company gets to the point where it doesn't believe that it can effectively reduce the workforce any further, the next logical step is to look for ways to get more out of whatever employee base remains. I suspect that that's already happening; if it isn't, then it probably soon will be. (This, too, shall pass... but maybe not anytime soon.)

I want to say right off the top: increasing productivity by making people work longer hours isn't the answer. It may work in the very short term, but it certainly doesn't over the long haul. All kinds of studies have proven this, to the point where I'm not even going to bother citing them here (this stance against sustained overtime should be accepted by now, I hope).

So how do people become more productive? Since this is an Agile blog, I'm talking here about the so-called "knowledge worker" industry, rather than something more manual-based, where productivity improvements often take the form of automation. It's much harder to replace a Computer Programmer, Project Manager or Business Analyst with a machine or a piece of software, so just how are productivity boons realized?

The answer that was already floating around when I first hit the industry back in the mid-80s was, "Work smarter." Now, it was also the case that not too many people had any notion of specific ways in which to accomplish that, but it was still a worthwhile goal. What I learned, over time, was that working smarter required a certain amount of reflection and adaptation, both of which fit quite nicely with the principles of Agile. Specifically, you could increase productivity if you were willing to root out, and then call out, parts of your process that were inefficient. The Toyota Lean Manufacturing approach essentially crystalized this mindset and represents the most pure application of it that I've yet encountered. It's one of those things that's easier said than done, though, and it requires a superior style of leadership that's quite frankly lacking in most organizations.

But even if you work in an environment that's not based around Lean, I think that you can still apply some of the same principles. Some of your success will be limited by how much empowerment exists, since making change in an empowerment vacuum is, if not impossible, at least ridiculously difficult. Therefore assessing the latitude with which you can effect change is probably the first step to take.

Assuming that you really do want to become more productive and you have at least some wiggle room within which to operate, then the next thing to do is look for obvious inefficiencies in your current processes. In Lean, I believe these are referred to as "waste." One way to spot these opportunities involves doing some sort of workflow analysis, paying particular attention to items that either introduce delays, or which seem to have limited value. There's more to it than that, but generally speaking you're taking a critical look at "how stuff gets done" and trying to identify those areas where the effort required isn't exceeded by the reward delivered.

As an example, imagine a process in which one step requires a meeting between representatives of several different departments, during which the various attendees provide feedback, and ultimately approval, on Business Requirements. It might be the case that setting up such a meeting often introduces a delay of up to several weeks, due to the lack of availability of the players. Therefore, you might actually be able to shave a project's timeline considerably if you could find a way to gather that same feedback and approval without requiring everyone to physically attend a meeting. Perhaps it could be done electronically, or in two or more smaller groups... regardless, the goal would be to see if it was possible to accomplish the same outcome without incurring the large elapsed-time cost.

In my capacity as Agile Manager, I saw something like this done with Code Reviews. The acquisition of a product called Code Collaborator enabled two improvements to occur: first, a dramatic increase in the amount of peer reviewing of code changes (thus, improving quality of the delivered product); and second, allowing developers and testers to review code at their desks, during breaks between other activities. The win-win nature of this change, whereby both the product's quality and the impact on the schedule were positively affected, made it an outstanding success story.

One of the biggest challenges to making changes toward improved productivity, of course, is that it involves change. As anyone who's ever moved to Agile knows all too well, change is hard. Some people resist it, and many of those individuals are quite adept at throwing up obstacles to any change that they feel threatened by. The introduction of Automated Tests, for example, may represent a huge peril to anyone who's built a career around manual testing. The trick, of course, is in helping those people see what sorts of operations Automated Testing is appropriate for, as well as re-purposing the human brains that used to do that work to something that can't be automated. It's not easy, but it can be done... and the end result is improved productivity.

Other types of change that may meet resistance involve switching up how others do their job. Even something as seemingly trivial as moving from a big meeting room setting to doing something electronically may cause some folks to recoil in disgust. They may actually like attending meetings, for one thing. But beyond that, they may have legitimate concerns about how effectively a set of requirements can be reviewed without the back-and-forth discussions that they're used to in those meeting rooms. How you handle those objections will go a long way toward determining how far you get toward your goal of productivity increases. As someone well acquainted with "inspect and adapt" these days, I recommend that you set up any alteration as an experiment, and then monitor the results so that everyone can see whether it's working out or not.

I think a basic question to be prepared to ask at every step is, "What value are we getting from this part of the process?" That can be an unpopular query to pose, especially when you get to the part where, for example, Bob's entire raison d'etre is called into question. You can bet your bottom dollar that Bob will have a handful of justifications at the ready for why filling out that form in triplicate (two of which get shredded) is a key component to the checks and balances of the entire company. Being able to handle situations like that require more tact than I could ever advise on, so don't be afraid to seek out your best diplomat in management if you find yourself down that path.

The bottom line, I guess, is that you can make productivity gains, if you put your mind to it. It just requires an analytical approach and a willingness to change. One of the alternatives, of course, is that all of your jobs get outsourced to a country where the knowledge industry works at less than half your rate... and nobody wants that, I'm sure!

Separating The How From The What

Poor AgileBoy!

One of the most common forms of "oppression" that I used to hear about in my role as Agile Manager involved Product people (or other representatives of management) going well beyond their mandate of providing "the "what" as they ventured into the thorny territory of "the how". I doubt that it was ever intended maliciously, no matter how much conspiratorial spice was attributed to it by the development team members... but if that's true, then why did it happen?

First, though, I suppose I should explain what I'm talking about. In most Agile methodologies, there's a principle that says that the Product Owner indicates what the team should work on - in the form of a prioritized Product Backlog - and the team itself figures out how best to deliver it. Thus, "the what" is the province of Product and "the how" is up to the team. It seems like a pretty sensible, straightforward arrangement, and yet it often goes off the rails. Why?

One cause for a blurring between the two can be Product people with technical backgrounds. We certainly had that in spades with our (aptly named) Technical Product Owners, most of whom were former "star coders" who had moved up through the programming ranks into management earlier in their careers. I'm sure it must have been very difficult for some of them to limit themselves to "the what" when they no doubt had all kinds of ideas - good or bad - about what form "the how" should take. In the most extreme cases, I suspect that there were times when our TPOs actually did have better ideas on how to implement certain features than the more junior team members did... but dictating "the how" still wasn't their job. In that sort of setup (where the Product area is made up of technical gurus), what would have been preferable would have been an arrangement where those TPOs could have coached the team members on design principles and architectural considerations in general, as part of the technical aspect of their title. That healthier response would have still accomplished what I assume was their goal - leading the team to better software choices - without overstepping their bounds and causing a schism between product and development.

Another factor that can result in people not responsible for "the how" trying to exert their influence on those who are, is a simple lack of trust. Again, I saw this in action many times as the Agile Manager. I'm not going to paint a black and white picture and pretend that it was always warranted, nor that it was never warranted. But the important point here is that dictating "the how" downward in that manner usually did more harm than good, and it certainly did nothing to close the trust gap. For one thing, having "the how" taken out of their hands gave those developers who were already skeptical about management's support of Agile more ammunition with which to say, "See? It's all just lip service! We're not really being empowered here!" It was also true, in some cases at least, that "the how" being supplied wasn't particularly well suited to the new development environment that was emerging. What with all of its automated tests, refactoring and focus on peer reviews, the code was resembling what "the old guard" remembered less and less with each passing Iteration. I experienced this first hand, as I'd make some small suggestion about how to tackle something that I thought might be helpful, only to get a condescending look and "Uh, it actually doesn't work like that anymore" from someone half my age. Yeah, that's tough on the ego, but it's also completely the right response.

As for why the trust gap was there in the first place, well... as both of my AgileMan books lay out in gory detail, lots of mistakes and missteps were being made. It wasn't exactly smooth sailing, let's say. The result of that, however, was that some among management apparently felt that the teams couldn't be trusted, and so they attempted to exert more and more control over them, in whatever ways they could. Had they simply applied that energy to improving the requirements gathering techniques being used within our organization, though, it would've benefited us more. Providing clear sets of Acceptance Criteria and good, well thought out constraints would certainly have done more to improve the product features that our teams were developing than any amount of "meddling" in the mechanics of the software development process itself ever did.

I imagine that it's often difficult to keep "the how" separated from "the what" as you work in an Agile environment, but it's critical that you do. After all, the people doing the work are in the best position to know how to do it, and that principle has helped make Toyota one of the premiere auto manufacturers in the world. We could do a lot worse than to follow their example in the Information Technology business!

A Horse Of A Different Colour

I'm venturing back into the work force on Monday, but with a twist. After 22 years of full-time employment, this will be my first experience as a contractor. Also, the work I'll be doing looks to be at least somewhat unlike anything I've ever done before.

I'll be performing a review of the development environment of a local company, in order to provide some guidance as they continue to refine their practices and processes. I think that I landed the contract on the strength of a couple factors in particular: my rather far-reaching involvement throughout my last employment as the Agile Manager, as well as the general breadth and depth of my resume, to date.

On that former point, it seemed relevant in the job interview that I had had some recent experience bringing change to an organization. I talked about how much I'd learned in the process, especially regarding the importance of being patient with people as they absorb information and evaluate it through their own personal filters. There's also naturally an element of trust required in something like that. I likened it to the expression about leading a horse to water but not being able to make it drink. My job often seemed to involve repeating that process, over and over again, until the horse finally trusted me enough (or maybe just got thirsty enough!) to take its first sip. (Not that I think of co-workers as horses! It's just an analogy!!)

By the same token, I think that the wide-ranging roles that I've performed over the past two decades also helped get me a foot in this particular door. I've worked on big mainframes and small client/server infrastructures; I've coded procedural algorithms (COBOL, C, Assembly language) as well as Object-Oriented solutions (C++, Java); I've been a "do-er" and a manager ("do-nothing-er"?); I've worked within well-understood roles but at other times had to define my own job. In fact, my resume, when I take the time to actually look at it (usually when I'm updating it), speaks volumes about the fact that I like new challenges. I've tended to change "jobs" (but not employers) at a pretty predictable rate of roughly every two years or so! And that's been true all along, showing that even as a wet-behind-the-ears programmer back in the 80s I was always looking for change as soon as I got comfortable with what I was doing. I think the pattern usually went: a few months of being a newbie, a year or maybe two of competence or better, and then on to the next thing. That cycle has given me a lot of varying experiences to draw on by now, it seems.

At any rate, I'll definitely be learning about a whole new set of parameters, starting next week. I'll be comparing what I see in front of me to my mental backlog of best practices. I'll be discovering what strengths and opportunities are in effect in an environment that's quite different than anywhere I've worked before, and making recommendations on each. And I'll be building up a bunch of new relationships, right from scratch. All of which sounds like something that should be right up my alley, I hope!

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.

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!

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.

What Should We Really Expect From Our Leaders?

One week into his new presidency, Barack Obama is still one of the most talked-about people on the planet. It's hard to go anywhere - even to websites dedicated to the discussion of comic books! - without bumping into references to the 44th President of the United States. And where once the focus tended to remain on the historic significance of an African American ascending to the highest office in the land, now the talk has turned to the more familiar territory for U.S. presidents: is he doing the right things? It's still much too early to draw any conclusions on that question, but I think we're beginning to at least get a better feel for the man.

One trend that's become apparent in Obama's actions, so far, is that he's focusing on the future, not the past. His Inauguration speech had several mild jabs at the previous administration, but they were made in passing, and only as a point of contrast for what he hopes to accomplish in the future. Consider this passage from the speech:

"But our time of standing pat, of protecting narrow interests and putting off unpleasant decisions -- that time has surely passed. Starting today, we must pick ourselves up, dust ourselves off, and begin again the work of remaking America."

The lasting images from that small section are not the ones that he begins with - that of lobbyists dictating government policy for a powerless electorate, and infrastructural and environmental concerns being shunted off to the sidelines by those in charge - because he quickly declares that period to be over, and instead paints a more encouraging portrait of the classic indomitable American spirit that built the country in the first place. In this way, he acknowledges the problems that exist currently but couples that with a commitment to address them. That's great leadership.

In another part of the speech, he says:

"The question we ask today is not whether our government is too big or too small, but whether it works -- whether it helps families find jobs at a decent wage, care they can afford, a retirement that is dignified. Where the answer is yes, we intend to move forward. Where the answer is no, programs will end. And those of us who manage the public's dollars will be held to account, to spend wisely, reform bad habits, and do our business in the light of day, because only then can we restore the vital trust between a people and their government."

Perhaps most telling in that quotation is the admission at the end of an existing trust gap between the government and those whom they govern. I think back to my former workplace and wonder, "Would any of our leaders there have been bold enough to own up to that in public?" It seems highly unlikely to me, and yet Obama does so on (literally) Day One.

While still somewhat lacking in specifics - and one would shudder to imagine what an Inauguration speech that was laden with minutiae would sound like! - that previous section of the speech lays out a blueprint for how the Obama administration plans to re-calibrate the American government. There's reflection, in the form of determining, for each existing program, whether it's working or not; there's accountability promised on behalf of those in charge; and there's an implicit commitment to transparency. Toward that final point, one need only visit the new and improved White House blog to appreciate what a new day has dawned in Washington. (Can anyone even imagine the Bush-Cheney administration operating within a similar aura of forthrightness?) Again, these are all indicators of great leadership.

One of the most-cited portions of the speech went as follows:

"To those who cling to power through corruption and deceit and the silencing of dissent, know that you are on the wrong side of history, but that we will extend a hand if you are willing to unclench your fist."

To fully grasp just how different a tone was set by these words, compare them to what George W. Bush said in his infamous "Axis of Evil" address:

"States like these, and their terrorist allies, constitute an axis of evil, arming to threaten the peace of the world. By seeking weapons of mass destruction, these regimes pose a grave and growing danger. They could provide these arms to terrorists, giving them the means to match their hatred. They could attack our allies or attempt to blackmail the United States. In any of these cases, the price of indifference would be catastrophic."

Bush offers no olive branch, but instead exclusively peddles the commodity that would later get him re-elected: fear. He paints the world in the sort of stark black-and-white terms that only a small child would buy into: that of pure-good versus pure-evil. "You're either with us, or you're a terrorist!" That's cowboy leadership.

Obama, on the other hand, acknowledges the threats that are still out there, but also provides hope for eventual peace. History may prove that he was too naive, but I think that we've already seen enough to conclude that Bush was too divisive in his approach. (Which is quite ironic, considering the man characterized himself as "a uniter, not a divider" during the 2000 campaign!) The world has been growing increasingly more dangerous for decades, but vilifying your enemies while keeping your populace cowering in fear can't possibly be the right response. Barack Obama, it appears, understands that there's no eventual outcome from such an approach that can jibe with the ideals so proudly proclaimed in his country's constitution. He has, at the very least, presented his people with a path that is no longer at odds with their espoused values. At the risk of beating a dead horse: that's great leadership.

Reflection, honesty, accountability, transparency and an alignment of actions to values (some might call that "integrity", I suppose)... those are all attributes that have already exhibited themselves in some of President Obama's words and actions in his first week in office. They also show up in many of the books about Agile, as well as in discussions of leadership. I happen to believe that those are all traits that we should commit to, ourselves, and that we should expect from our leaders. Anything less should simply not be acceptable.

Giving Feedback

A couple of recent events have gotten me thinking about feedback.

The first incident was an offhand comment that a friend in management made to me while we were talking about something else. In mentioning that he'd just had a one-on-one with a staff member, he casually tossed off the fact that it had gone very quickly "because that person is doing a great job." That got me thinking about how we sometimes perceive meetings with employees as being issue-driven. In other words, a manager might consider that her only responsibility in a one-on-one is to respond to anything that the employee brings to her attention. To be sure, that's part of it: if someone who reports to me expresses concern that he doesn't have the equipment that he needs to do his job, has a conflict with a co-worker, or demonstrates a desire to get training in a particular area, then it behooves me to take that information away and do something about it. That's what I tend to think of as the reactive aspect of management. Any manager who doesn't pull off at least that much of the role is really hurting (in more ways than one) and should consider either stepping up his game or moving to a less-senior position in the company.

But less obvious to some is the proactive part of people management. Going back to the example above, someone who's "doing a great job" is every bit as deserving of feedback as the employee who's got a beef, is visibly struggling or has been causing problems for others. The reality, of course, is that often the "great job" folks don't get much attention from their managers because they don't represent the proverbial burning fire in the way that the more reactive situations do. While that may make some logical sense - at least to those of us who've been in management and experienced the "crisis du jour" scenario in all its glory - it's also kind of ass-backwards, if you think about it. After all, here are the stars and superstars of your organization, and they're the ones that you basically leave to their own devices, while you focus all of your attention on everyone else. It can certainly be a tough trick shot to pull off, but what's really called for in that situation is that the manager spend a non-trivial portion of her time providing morale-building feedback on those areas that her best performers are excelling at, as well as coming up with new goals and challenges that will excite, inspire and motivate them to grow even further.

And if you can do that, then it's unlikely that any one-on-one get-together will ever be particularly short!

The other recent trigger for feedback thoughts was the time I spent earlier this week reviewing a draft copy of Mike Cohn's next book. This is something I've been doing, on and off, since late last year. I'm a big fan of Cohn's previous works, as well as a two-time attendee of his Agile Estimating workshop series. Because of that, I was more than happy to set aside some time to provide feedback on a selection of chapters within his upcoming Succeeding with Agile book.

Despite having no professional experience whatsoever in the field of editing, I happen to think that I'm pretty good at it. (That could, of course, be entirely delusional on my part!) For material of this sort, what Mike usually gets from me are comments that fall into the following broad categories:

• booboos: typos, spelling mistakes, grammatical errors, wrong words used
• flow problems: poor transitions, leaps of logic, unsupported conclusions, contradictions, wandering points
• missing bits: unaddressed concerns, partial lists, problems with no solutions
• suboptimal choices: examples that seem weak, repetitive wording, sentence structures that sound wrong if read aloud
  
• positive reinforcement: places that really worked, humourous parts that made me laugh, sections that especially resonated with me

In each case, I give specifics (pg #, some piece of text that can searched on easily, and whatever point I'm trying to make) because I want him to at least understand what I'm saying... whether or not he agrees with it, is up to him. It's an easier relationship than the manager one that I wrote of up above, because there's really no onus on me, in this case, to convince Mike to change a single thing in his draft. That's not my role here, as he's not working for me and I'm not in any way responsible for the contents of his book. But that still doesn't mean that I should take the task of giving feedback lightly (which I don't), or that I should simply throw a bunch of vague, generalized observations his way and let him make of them what he will.

As someone who's recently been on the receiving end of review feedback (not just once, but twice!), I know first-hand just how valuable it is when it comes in the form of specific, clear communication. I was pretty lucky in that regard, but then again I chose my reviewers fairly carefully. In general, I'd strongly recommend that if you're ever asked to provide that sort of thing in the course of your travels, simply put yourself in the other person's place, and then give the kind of feedback that you'd consider the most valuable were you receiving it. (That old Golden Rule just turns out to have so many applications, doesn't it?)

By the way, if you'd like to similarly review some of the chapters of Mike's book, you can do so here.

Great Leaders Don't Play The Blame Game

Watching a Sunday morning news program today, I heard an expression that took me back to my days as Agile Manager. The comment was made in relation to the current economic woes facing the U.S. (and the rest of the world) and was in response to the question of whose policies really caused it. The answer given was, "There's plenty of blame to go around!"

I don't dispute the factual veracity of that assessment, as it's almost certain that multiple parties failed in various ways to carry out the responsibilities of their positions. It wasn't just the banks that screwed up, or the legislators, or the people who are supposed to enforce the rules, or even the people borrowing more money than they should have. It took all of that misbehaviour and more to bring the world economy to this point.

At my last job, the same thing was true. We didn't typically experience failures, whether large or small, because of just one person somewhere dropping a single ball. Instead, it was usually a more widespread problem, involving roles like Vice President, Project Manager, Product Manager, Product Development Leader and Product Development Team member. I honestly don't believe that any of us in those types of positions were "without sin" and therefore free and clear from accepting a share of the blame for how things went.

However... Where I didn't always see eye-to-eye with some of my peers and superiors on the topic of the Blame Game was in the relative weight that should be borne across the players. Rightly or wrongly, I've always operated under the assumption that management needs to be held to a higher bar. I felt that way before I joined the management ranks, and I've continued to subscribe to it since then, as well. One small indication that perhaps I'm not so out there in my thinking comes in the area of the law. As anyone who's been a manager knows, you only get that title with the accompanying caveat of a greater legal responsibility (and liability) should something go wrong within your work environment. For example, managers who allow a poisoned work environment to form around them, regardless of whether they actually contributed to it or even condoned it, can be held every bit as accountable for what happens within it (sexual harassment, violence, racism, etc) as the perpetrators of those acts. That's a very high standard, and it can be quite intimidating to learn that you're suddenly in that position upon promotion. Talk about a "good news, bad news" scenario!

But it works that way because the bar is higher. Pay scales are generally elevated, you're going to influence more people simply by virtue of your title and position, and expectations around your behaviour and composure are going to be greater. Those are all part and parcel of the package that comes with moving up that rung of the organizational ladder.

With that in mind, it's apparent to me that when things go awry, it's always going to be the higher-ups who must assume the lion's share of the blame. That may be perceived by some as being every bit as "unfair" as the example above within a poisoned work space, but it's also every bit as appropriate, as far as I'm concerned. In fact, it's something of a telling trait (to me, anyway) when a person in a leadership role complains about the seeming inequity of it. The best leaders understand that it comes with the job, I think, and they don't waste time talking about how "there's plenty of blame to go around." Instead, they accept that all problems are theirs to address (directly or indirectly) and a failure by anyone below them on the org chart is still a failure on their part. It can be a bitter pill to swallow - and I say that from experience - but it's also a component of what separates great leadership from those of us who just hold the title and collect the big paycheques.

Bringing this back to U.S. politics, my take so far on Barack Obama is that he is, and will continue to be, a leader who sees the futility of the Blame Game and knows that the buck will always stop with him. I think he'll spread credit for successes around liberally (another great leadership trait), but will conversely accept the blame for the failures himself... at least, I hope that he will!

Competence And Confidence Go Hand In Hand

Following up on my last post, I saw this great commentary about the relationship between competence and confidence in a recent Time magazine article. The piece is about Obama's plans for what to focus on first when he takes over as President of the United States. This particular paragraph falls in the middle of a section about the dire straits within the financial market right now, and what the new President will need to do in order to right the ship:

"Just like its banks and its carmakers, America's shattered confidence is in serious need of a bailout. And the thing about competence is that it nourishes fresh confidence. 'Yes, we can' is both an affirmation of optimism and the essential claim of the competent. When the slogan is rooted in a record of accomplishment - when tomorrow's yes-we-can is backed up by yesterday's yes-we-did - confidence and competence begin to feed on each other. This virtuous cycle of possibility isn't the whole of leadership, but it is an important part and perhaps the element most needed in today's sea of troubles."
- David Von Drehle, "Why History Can't Wait", Time magazine, Dec 29/08 - Jan 5/09

I think that's a very key perspective on leadership, and one that I wholly subscribe to. Nothing rattles the confidence of people quite like the fear that their leaders aren't up to the job. George W. Bush's record, especially over the past couple of years, illustrates that point painfully well.

For anyone in a leadership position today, my advice (for whatever it may be worth) is this: Establish a record of saying what you're going to do and then doing what you say. In other words, as the preceding article put it so eloquently, work hard to ensure that tomorrow's yes-we-can rah-rah speech is in fact given some weight by yesterday's yes-we-did track record. That simple feedback mechanism, implemented in the form of weekly updates, All-Hands meetings, newsletters or whatever, will build up so much confidence among those whose fortunes you're in charge of, that you'll soon find that they'll follow you wherever you lead. Failure to do so, on the other hand, as we've all observed so many times in our travels, will lead to situations like we have in the U.S. financial sector at the moment.

Competent, Not Complacent

Of all the controversial bits that I wove into the fabric of my two AgileMan books, it's probably true that nothing else was as likely to fan the flames of disgust - in certain quarters, at least - as my none-too-subtle questioning of the competence of some of those among our leadership group (myself, included, at times). It's not at all surprising that unflattering categorizations such as "borderline incompetent" would upset some, as they in fact did. Frankly, similar views expressed on my work blog (at the time) received the exact same chilly welcome, and that eventually led to me shutting down that particular avenue of communication (as described in More Real-Life Adventures of AgileMan, Issue # 45, Can We Not Talk?).

It was with great interest, then, that I read the following section in Barack Obama's book, The Audacity of Hope:

"[I value] competence. Nothing brightens my day more than dealing with somebody, anybody, who takes pride in their work or goes the extra mile - an accountant, a plumber, a three-star general, the person on the other end of the phone who actually seems to want to solve your problem. My encounters with such competence seem more sporadic lately; I seem to spend more time looking for somebody in the store to help me or waiting for the deliveryman to show up. Other people must notice this; it makes us all cranky, and those of us in government, no less than in business, ignore such perceptions at their own peril."

Now, I'd never be so pretentious as to compare myself to President-Elect Obama. After all, he's a great man who's overcome incredible odds to reach the highest office in the most powerful nation on Earth (and is the author of a couple of best sellers), while I'm an unemployed schmuck who was unable to get Agile successfully implemented into a mid-sized company (and had to self-publish his two books about the experience). And yet... if nothing else, we two have in common, apparently, a dissatisfaction with the laissez-faire attitude toward incompetence that others seem to exude when they encounter it.

Beyond that, much of what Obama writes about in his second book revolves around the notion that even unwelcome viewpoints should be discussable in our society. In his context, that can mean Democrats and Republicans being ready, willing and able to sit across the table from each other and talk productively about hot-button topics like abortion, regulation and health care without either side shouting down the other or shoving their fingers in their ears. I suspect that Mr Obama is the sort of man I'd enjoy working for or with, although I have my doubts as to just how well I'd live up to his obviously-high standards. At the very least, though, I doubt that he'd adopt a stance of "I agree with what you're saying but just don't think you should be saying it" as I experienced (on a few occasions) during my time as Agile Manager.

I also agree with the "ignore such perceptions [of incompetence] at [your] own peril" sentiments with which Obama closes that section. That head-in-the-sand attitude was clearly an issue in my former workplace at times, and continues to contribute to morale problems there even now (despite the most obnoxious voice of dissent - mine! - removing itself from the mix). Just as children naturally expect their own parents to be perfect authority figures, most people in subordinate roles desire to be led by not just competent, but hopefully "superior" individuals (in terms of skills such as decision-making, job knowledge, reliability, trustworthiness, etc), safe in the knowledge that everyone involved is doing their part (or more) to ensure success. Great leadership inspires everyone around it; anything less has the opposite effect, unfortunately.

The further I get into The Audacity of Hope, the more impressed I am with the character of its author and the leadership qualities that he embodies.

Trust Isn't An Option... It's The Only Option!

I was reading an article on the woes of "The Detroit Three" (automakers) this afternoon, and came across this fascinating bit about the New United Motor Manufacturing Inc (NUMMI) plant that was a joint venture between GM and Toyota, starting in 1984:

"The plant had [previously] been one of GM's worst; the Toyota system made it one of GM's best.

Detroiters made the pilgrimage... en masse to see the miracle of NUMMI. Some dismissed what should have become a model for the entire industry. True, the technology wasn't that innovative. But Toyota made the workforce integral to improving the system. Workers were not mere labor inputs. GM had no problem understanding the just-in-time inventory system Toyota used, but executing it required a buy-in from the shop floor so that everyone was dedicated to improvement. The Toyota system, says John MacDuffie, a manufacturing expert at Pennsylvania's Wharton School of Business, 'relies on contributions from employees. It feels vulnerable, but your willingness to be open to that vulnerability is what helps you make it work.' In the 1980s and part of the 90s, the top-down culture of the Big Three could not absorb that kind of deep trust."
- Bill Saporito, "Is This Detroit's Last Winter?", Time magazine, Dec 15/08

Those who've read the 2nd AgileMan book, especially Issue # 46, Who Do You Trust?, will perhaps recognize that the preceding description bears at least some similarity to what I observed in my role as Agile Manager. Lean manufacturing (as Toyota created and mastered), like Agile software development, requires that a greater degree of trust be extended to the "rank and file" than many traditional management types are ready, willing or able to accomplish. It sounds like the Big Three suffered from that, and I certainly saw lots of evidence of the same issue in the workplace over the last several years.

So just how can you place trust in the employee base and be comfortable in doing so? Well, we didn't pull it off all that successfully, but I still believe I learned a thing or two along the way. Here's what I think it takes on the part of those in charge:

1. Clearly communicate what's expected of those you're entrusting. In our software environment, that means telling everyone "the what" and empowering them to come up with "the how". I personally think it's unreasonable (and doomed to failure) to dictate both "the what" and the "by when", but others may disagree with that.
   
2. Establish how the results will be measured, make them well known, and then follow through on what you established. Metrics are tricky business (as I wrote about in the 1st AgileMan book), but just because they're hard to do right doesn't mean that you get off the hook for producing them! The temptation to shift around the measurements as time goes by is often very strong, but also completely unfair to the people whose hard work is being evaluated. The onus is ultimately on management to set the yardsticks and then to live by them. Failure to do so causes the staff to believe that you're changing the rules as you go... because you are!
   
3. Treat the inevitable failures that will occur as opportunities for learning. This is another tough pill to swallow, because those who live by the Blame Game rules (and who have long since mastered "Cover Your Ass" as an integral skillset) will find it difficult to re-wire their brains to this new way of thinking. Finger-pointing and general CYA attitudes, however, do more to erode trust than just about anything else you can throw into the mix.
4. Celebrate successes, large and small. This was perhaps the biggest disappointment for me in my previous job: the focus always seemed to be on what had gone wrong, rather than on what had gone right. If one Feature Team did really well, management would only want to talk about the ones who were still struggling. If a team got their bug count significantly reduced, the focus would go on to how "late" their new features were. Despite providing hundreds of features in our first 2 years of Agile, I repeatedly heard executives say, "We haven't delivered a single thing since we started Agile!" That sort of skewed perspective is certainly not a good way to build trust between the layers of the company!

If you can pull those four areas off, you'll probably do very well in creating an empowered, high-performing environment in which everyone will succeed. If, on the other hand, you regard trust as an optional add-on, like power windows or leather seats, then you'll probably be sorely disappointed in the results you get each time you "cheap-out" in that regard.

The Leadership Game

One of the concepts that I first came across when I began reading up on Agile (waaay back toward the end of 2005) was that of servant leadership. There's a nice Wikipedia entry for it here, in case you want to know more about its origins and interpretations.

While I served as Agile Manager for two years, I tried to embody the notion of servant leadership, with admittedly mixed results. In my first tenure as a Feature Lead (in those initial month-long Iterations with the group that I nicknamed the "B-Team" in my books), I tried to drive home the point that, even though I was an Engineering Manager, I wasn't there to tell them what to do. I was there, instead, to help them succeed. My job was to serve their needs in the best way that I could. Similarly, in some of my other roles during that period, I tried hard to reinforce that same message. Not everyone bought into that kooky approach, though, with some still preferring to defer to me at the drop of a hat. As well, some of my fellow management brethren believed that a heavier (or perhaps, just steadier) hand was required on the steering wheel and thus found fault with my style.

I suspect that such reactions may have stemmed from the fact that some of those same leaders weren't ready themselves to do much more than perhaps pay a bit of lip service to the cause of "leading by serving." Thinking back on it now, I can come up with several different reasons why that might have been so, which would likely vary by individual:

• Sometimes egos are just too large to allow a person to think of himself or herself as "serving others" as a member of management. If you're career-oriented, after all, you probably worked hard to achieve that lofty position, and so why would you lower yourself (back down) to the point where your success could be measured in terms of how much you help others succeed?
• Some people, sadly, have little or no natural ability to influence and thus their leadership style is strictly Command-and-Control because nothing else ever works for them! In that situation, relinquishing some degree of decision-making onto subordinates and then filling your time supporting them in their efforts would be frightening, at best, and incomprehensible, at worst.
• Along the same lines, I think that a few of the managers and executives quite simply don't trust those below them on the org chart. How can you commit yourself to the service of others if you suspect that they're incompetent, unmotivated or just plain lazy? Believing in people often requires a huge leap of faith, and I'm not sure that all of my peers and superiors have been willing to take it.
  

There were other factors at play, as well, I'm sure. But when I conjure up images of some of the "worst offenders" (as measured against this particular leadership bar, that is), those reasons above seem to be the most common.

Something I read recently talked about how important humility is in a great leader, and I think that fits perfectly with servant leadership. Being humble often gets a bad rap... Clark Kent, after all, is described as "mild-mannered" but most of the time that's used as a knock against him. "Why can't you be pushier, like Lane is?" editor Perry White would demand of him. "Nice guys finish last, and don't get the by-line!" I happen to believe that humility's a virtue, because (among other things) it tends to keep your eyes and ears open a lot more than arrogance or even pride ever does. If you accept that you can always do better, for example, then it's more likely that you just might! On other hand, if you're already convinced of your own greatness, there's really nowhere to go (but down).

So if I were building up a new team of leaders today, I'd be looking for at least some healthy amount of humility in each selection. When I took part in the task of finding several new Product Development Leaders (Agile Coaches) for our company earlier this year, I certainly factored that into the search criteria that we used. Anyone exuding a sense of born leadership, for example, was facing an uphill climb, as that attitude seems to suggest that there isn't much to learn in becoming an effective leader (with which, I must most humbly disagree). If a person came across as looking to finally get their chance to wield some power over the folks who were always disagreeing with them, I'm afraid they were similarly at a disadvantage. While some degree of self-confidence is obviously required to lead, we also recognized the need for a healthy dollop of modesty in our candidates, and I think the ones who eventually made the grade all demonstrated it. If all of the current leadership had been screened with an eye toward that attribute, we might have actually fared better in our Agile journey... although that's certainly open to debate. A better Agile Manager would've similarly helped, but we didn't get that, either.

With the U.S. election just barely a month behind us now and a new President-elect in the process of transitioning into power during a frightening economic meltdown, the word "leadership" is getting a lot of play in the media at the moment. I suspect that Barack Obama is the type of man who understands the job in front of him, and gets that the only chance he has of success involves him inspiring great things in others. He comes across as someone who has a vision of how to turn his country around, especially in terms of how to take it into the 21st century (after his predecessor tried hard to send it back to the 19th). Because of the office he's assuming, he'll naturally make many decisions and give lots of orders; but his greatest achievement, if I'm right, will come from empowering not just his cabinet and fellow politicians but also the American people in general. He's smart enough to realize that he can't possibly fix all of his country's problems alone, and so part of his job will be to remove obstacles and thereby enable several million other people to contribute to the solutions. I wouldn't be at all surprised if he ends up providing a model of servant leadership that we all could learn from.

If you're currently in a leadership role (at work or elsewhere), it wouldn't be the worst thing you could do to stop, take a moment, and consider: what am I doing that's actually in the service of those "below" me? If you have a tough time coming up with a very big list, then maybe it's time to shake things up a bit and see what happens!