Getting What You Asked For

Sometimes I draw inspiration from the strangest of places!

In this instance, it was reading about how some well-intended school testing backfired on those who'd introduced it. In their fascinating book, Freakonomics, economists Steven D. Levitt and Stephen Dubner describe the results of some deep analysis that was done on 3rd to 7th grade testing within the Chicago Public School system around the end of the 20th century. Even prior to President Bush's No Child Left Behind initiative, the CPS had instigated city-wide testing in order to ferret out the lowest-performing schools. The worst offenders faced suspension or even closure, and individual teachers could see rewards and punishment ranging anywhere from promotions to demotions or even job termination as a result of how their students did. All of which makes for a very interesting incentive scenario, indeed!

Levitt and Dubner make a good case for how such a setup can often cause the exact opposite effect compared to what had been intended. I'd written of something similar in the 1st AgileMan book (Issue # 22, Who's Measuring What Now?), where Call Centre agents were graded by how quickly they got through each call... thereby encouraging some of them to hang up on the callers! In the case of the Chicago Public Schools, what a certain (non-trivial) percentage of the Chicago teachers did as a result of the new standardized testing wasn't any more surprising: they cheated!

Specifically, these counter-incented instructors found ways to make their classes' results better than they should have been. That included prepping their classes exclusively for what would be on the tests, giving them extra time, helping them figure out the right responses during the tests, or even changing the results on individual student's answer sheets! Freakonomics provides a highly entertaining recounting of how the cheating teachers were found out (hint: it involved some awesome data-mining!) but what's relevant here is the lesson that can be learned about how you really do need to align your incentives (positive or negative) with your over-arching goals.

The school testing was put in place to improve the education system in Chicago, but because it was implemented in a less-than-perfect way, many of Chicago's elementary school teachers were being encouraged to behave in a manner that actually made things worse! Not only were some of the struggling students, teachers and schools not being identified (thanks to the cheating), but it was also bringing out the worst tendencies in many of the people charged with molding the next generation of Chicago-ites. Just imagine what students learn while watching their role model cheat on their behalf on a city-wide test! That's the kind of damage that's hard to undo!

A better incentive plan, I have to assume, would be one where the measurement is both better-monitored (in order to reduce the opportunity for cheating) and more targeted toward helping, rather than punishing, those found wanting (thereby removing the motivation to cheat). Of course, it's always easier to "Monday morning quarterback" other peoples' mistakes than it is to get it right yourself!

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.

Happy Holidays From AgileMan

Here's hoping everyone is enjoying a wonderful break right now before launching into another exciting year... I certainly am!

Not All Change Is Good Change

Ever since taking on the Agile Manager role two and a half years ago, I've become much more cognizant of examples of adaptation occurring around me than I ever had been before. I see it lots of places, from online surveys that I receive (and am more inclined to fill out than I had been in the past) to friends imparting insight that they've gleaned from training of one sort or another. I stepped into this whole AgileMan gig several years ago as someone who was traditionally very resistant to change - and wasn't afraid to admit it! - but what I've come to realize since then is that I'm really only opposed to bad change. So what do I mean by that?

I think there are several types of bad change, and looking at a couple of them even briefly as I'll do in this post will undoubtedly shed some light on some of what can make change a more positive experience. One obvious example of the wrong sort that comes to mind is "change for change's sake." This might come in a case where someone (or some group) is unhappy with the way things are but won't spend the time or energy to figure out why. I had one friend, many years ago, who left a job because he didn't think that it was fulfilling enough for him. When I asked him what specifically had been missing, he couldn't actually come up with anything concrete ("It's just a feeling"). The job that he moved to, however, turned out to be even worse than what he'd given up. Before long he became extremely nostalgic about the old job, and subsequently did everything that he could think of to try to get it back. When he failed in that attempt, his misery just intensified. From what I could tell, he had made a change without having any real idea what the driving force behind it was, and ended up quite unhappy as a result.

Another type of bad change is "throw away whatever I don't know and replace it with what I do know", which is really an anti-change for the person driving it. This can often exhibit itself in the form of a management type who either wants to make his mark on an organization or only knows one way to work, for example. Often such an individual will therefore rush to sweep out whatever "the last guy" implemented in order to either avoid having to learn the old system or just to re-shape it into something he's more familiar and comfortable with (or maybe both). While such a change may ultimately prove to be the right move for the organization, it's a poor approach to take for several reasons. For one, you end up throwing out the baby with the bath water, since you have no idea what working processes may get kiboshed in the process. For another, you run the risk of alienating those in the organization who liked or even believed in the old way of doing business, without first giving them a chance to draw attention to the working bits.

A common thread between both of those preceding examples is lack of data. And that's really what's often missing when the wrong kind of change is introduced. There's the data about what's currently going right and what isn't, and there's also gold to be mined as far as what effect any change you introduce is actually having. "Adaptation", as distinct from the more general purpose "change", requires that there be a feedback mechanism in place to provide that data and allow those involved to evaluate and respond to it. There's an old joke about a guy going to a doctor and saying, "Doc, it hurts when I go like this" (waving his arms up and down like a chicken)... to which the medical expert wisely replies, "So don't go like that!" The patient wasn't adapting to the data that he was receiving (pain while doing something silly), but doctors are all about paying attention to data. They listen to what the patient says, to what the patient's medical and family history tells them, and what various test results indicate... and then they respond accordingly. Smart, adaptive patients follow their doctors' directions on matters of health; the rest of the population keeps smoking/drinking/not exercising with no regard to what the effects might be, and then get eulogies that speak of how their lives were cut unfairly short.

As I said at the start of this, I've been seeing bits of adaptation almost everywhere I look now, and I think that's a very good thing.

In The Black

That's right! Thanks to the kindness and generosity of our many readers, the two-pronged publishing project that included More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done) and The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile) has now achieved profitability! It took a few months for that milestone to arrive for the first AgileMan book, but less than a week this time around (the difference that not providing a couple dozen comp copies can make!). And I'm not counting the 8 copies that were pre-ordered but not distributed/paid for yet, which means that I'll soon have taken enough in to pay for another (smaller) print-run if there's ever enough demand for it.

Many thanks to all who've purchased either book, and especially to Jamie who bought four copies to give away (once again)!

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!

The Books Are On Their Way!

I just received e-mail notification from Lulu that the initial print-run of More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done) and The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile) has been completed and several dozen copies are now winging their way here! It's always a bit tricky guessing exactly when they'll arrive, but I'd say Monday or Tuesday of next week looks promising.

If so, I should be able to get books out to my former co-worker buddies who pre-ordered sometime later next week, which would be excellent (several weeks earlier than I had planned). I still need to figure out how to accomplish that mass distribution (and currency collection), but now that it's starting to seem real, I'll put more thought into it!

Another publishing cycle nears its exciting conclusion...