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...

Book Publishing Running Ahead Of Schedule

I was very happy to see this week that Lulu, where I print my AgileMan books, was able to produce and deliver the print drafts 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) in less than a week! I ordered them Sunday afternoon and they arrived the following Friday! That's quite impressive and in fact exceeded my expectations by about 50%. (That's the good news; the bad news is that even their cheapest shipping option is now more expensive than it used to be, meaning that they've already started eating into my profit margin before I even sell the first copy!)

After Vicki and I checked over what had arrived, I made a few minor tweaks and then placed an order large enough to cover all of the requests that have come in to-date plus a handful of extra copies of each book. Based on the estimate provided by Lulu on the order, I would think that they might arrive sometime during the week of Dec 15th, or possibly earlier if I get really lucky. It's hard to predict just how much things will slow down in December because of holiday-related activity, though. It's still possible that the books won't arrive until after Christmas, which would be more in line with what I imagined when I planned out the self-publishing schedule leading up to this.

In any event, we're on the last leg of the journey for the 2nd AgileMan book, and those of you out there who are eagerly awaiting it (c'mon! stand up and be recognized, both of you!!) should know that it won't be much longer before you have it in your hot little hands. I still have to figure out, logistically, how I'm going to get copies to all of those people at my former workplace (I can't exactly book a meeting room for it, after all!), but I'm sure that we'll figure something out.

New Mike Cohn Agile Book In The Offing

I stumbled across this link to a website where you can download and preview a few draft chapters from Mike Cohn's upcoming book, Succeeding with Agile. I'm not sure which excites me more: the fact that Mike has a new book coming out, or that he's providing the option for interested parties to preview the work and give feedback on it ahead of publication!

Anyway, I definitely encourage other Agile enthusiasts out there to do what I'm about to: visit the site, check out what Mike has to say and help him make the book even better!

Let History Be Your Guide

I was asked an interesting question yesterday, thanks to the magic of Instant Messaging. One of my friends at the company that I used to work for (in my capacity as AgileMan) wondered if either my wife or I had ever heard of something called "empirical forecasting." We hadn't, but as he told me more about what he'd been reading (and even shared some of it with me), I realized that it was something that I'd been practicing during the final few months of my employment. It's also a topic that I wrote about briefly in More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), although you'll just have to take my word for that until the book actually comes out! I just hadn't had a fancy name for it, until now!

Basically, that style of forecasting or planning involves using the empirical (or observed) data that you have, and only predicting what can be extrapolated from it. In other words, you only expect to get results that match what you've gotten in the past. That may sound obvious to some, but in my former company, it was rarely the way planning occurred. I sat in countless meetings in which statements like the following would be made:

"Our owners need ______ (some set of features) by ______ (some date in the future) so now we need to figure out how to deliver it."

Put another way, we'd start at a desired outcome and try to work our way backwards from it. I completely understand why we always felt that it was necessary to do things that way, but repeated failures of that approach should have incontrovertibly shown the folly of it at some point. Instead, it continued to happen.

What works much better, I believe, is to base your schedules on what has been proven in the past. For example, our development teams each had a certain average velocity (in Story Points) that they'd worked at for the past N Iterations (where N could reasonably be any integer between 3 and 6, let's say). Realistically, if that's what they did in the past, it's likely going to be close to what they'll do in the future. Therefore, you should expect about the same productivity going forward, and anything beyond that is just wishful thinking. If a team has 100 Story Points of work left, for example, and they work at an average velocity of 15 Story Points each Iteration, then you could reasonably assume they'd finish all of the features in roughly 7 more Iterations, with the caveat that the "remaining work" doesn't change dramatically in the meantime. What would happen all too often in my former workplace were frantic meetings in which endless discussion would ensue as to how to shorten that timeframe down to 3 or 4 Iterations. In the end, of course, it would still take 7 Iterations, or even possibly longer, if enough churn had happened in the process such that it actually made additional work for those involved!

In my conversation yesterday, the other person even talked about using simple line graphs to predict when the work remaining would hit zero, including accounting for features that have been added or removed. I think that sort of graphical representation can certainly help in such matters, as some people relate better to pictures than to words. In either case, though, your expectations are limited to an extrapolation of what's already happened, rather than relying on the time-honoured "... and then a miracle occurs" (as we all used to fall back on for those impossibly-hard university math exam proofs!).

In order to use this sort of technique, of course, you need development teams that can become fairly good at providing relative estimates (such as Story Points). That's no easy challenge, but it's also a big enough topic to warrant a separate blog post, and so I won't tackle it here!

2nd AgileMan Book Nearing Completion

I'm now into the home stretch on More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), as I'm about to embark on a final read-through before beginning the self-publishing process. I'm still awaiting feedback from one of my reviewers, but that seems to be par for the course in this sort of arrangement (the same thing happened with the first book, even though the set of reviewers this time is completely different). Depending upon when it arrives, this final array of comments may - or may not! - end up being reflected in the finished product. As tempting as it might be to hold things up and wait, I'm keenly aware (after 22 years of doing various types of projects) that it could end up being a long delay. So onward and upward we go!

Vicki and I spent some time toward the end of the week (after we'd concluded our Project Management guest lectures) designing the covers for the 2nd book and the collected edition. The former will use a standard Lulu cover image, just like the 1st AgileMan book did, but I'm doing something special for The Complete Real-Life Adventures of AgileMan (Two Years of Lessons Learned in Going Agile). And yes, that means I finally decided on a name for the collection! I've had 5 pre-orders placed for the bigger volume so far, and I think those generous souls will be amused, and maybe even pleased, to see what their book's cover looks like! I still have one more extra in mind for that edition that I'll probably take care of tomorrow.

If things go well this weekend, I hope to be placing an order for one copy of each of the two new books sometime very early in the week. With the American Thanksgiving holiday looming on the horizon, I imagine it may take more than the (now) standard two-week turnaround to get them, but I'll optimistically say that we might have the first proof copies in hand toward the end of the week of December 8th. If so, that would work out well for having the first big shipment arrive in time for early January distribution (an even luckier outcome would have the books show up before Christmas, but I don't see that as likely at this point).

Project Management In An Agile Environment

Last night, my wife Vicki and I traveled to our local university where we'd been invited to provide guest lectures to an evening class made up of third year Computer Science students, all of whom are enrolled in a course on Project Management.

Vicki wanted to go first, and so she took up the first forty-five minutes (of a 3-hour class) describing several of the jobs that she's had over the years that didn't, at first glance, appear to be related to Project Management... and yet were! The overall message of her talk was that there are more types of PM jobs out there than you might think, and the students seemed both interested and encouraged to hear that viewpoint! Although she was nervous going in, you'd never have known it to watch her... and she's now much more confident of her own ability to present on that topic.

My portion of the proceedings ended up taking close to 2 hours, in part because I had more material to cover (more on that in a moment) but also because I got asked a lot of questions! Although a handful of the inquiries were slightly skeptical in nature ("Could you really get a customer to approve spending money if you're not promising to deliver on time?"), most were more obviously related to them beginning to connect the dots. Which leads nicely into what my talk was on.

I broke it into 2 parts: What is Agile?, and What do PMs do in an Agile world? Because I had to assume that they had no knowledge of Agile prior to this (which turned out to be mostly accurate), it seemed critical to me when I was planning my lecture to give them a sufficient grounding in it before moving on to the Project Management angle. Based on how things proceeded, I'd say that was a wise choice.

Because it was a PM course, and I'd taken a look at their curriculum online, I decided that it was appropriate to frame Agile within the context of how common it is (and has been, for decades) for software projects to fail... a topic that I knew they were well familiar with. I provided some ideas of my own as to why the failure rate has always been so high, and then showed how - if done properly - Agile might address some of those factors. An actual PM from my former job was in the audience, and was nice enough to offer up some good observations to the class about areas where Agile had actually helped.

Before I moved into the second half of the material, I decided to get everyone up off their butts in a goofy little move where I had them stand up and give me an enthusiastic "but but but" as I launched into some of the more obvious reasons why Agile, as I'd described it up to that point, might seem like pure poison to a group of project management enthusiasts. You never know how that sort of thing is going to fly, but at least they played along and it kept them having to sit still for the entirety of the 2 hours!

I had 8 aspects of Project Management that I discussed, in turn, showing how a PM would add value in an Agile organization while doing the role in a manner different than what they might expect:

• Requirements Gathering
• Task Estimation and Tracking
• Project Planning
• Personnel "Management"
• Quality Assurance
• Customer Relations
• Status Reporting & Milestones
• Scope Management

Each of these prompted questions from the students, none of which were silly or indicative that they didn't understand the subject matter. They were simply absorbing it all, quite quickly, and beginning to draw conclusions or anticipate problems. Fielding all of their questions, including several by the course instructor himself, was definitely the most challenging part of the evening for me. That also, of course, made it the most rewarding!

Both of our presentations appeared to go over very well, and we came away feeling as if we'd done a good job. Those of you who know people in the course are free to seek out differing opinions, though!

A Few Updates On The 2nd AgileMan Book

I've begun soliciting pre-orders for More Real-Life Adventures of AgileMan (Year 2: Easier Said Than Done), starting with the list of people who bought or expressed interest in the 1st book. I've had nearly 20 positive responses so far and that's an encouraging result after just a couple of days!

Since I've decided to produce a collected edition of the two books, I'm also looking for pre-orders on that (I have 2 so far!). I've been working on the bonus material for it recently, making sure that anyone who buys the collection gets a little bit of extra, fun stuff beyond what's in the two regular editions. I'm still noodling over the sub-title for that book, to go along with The Complete Real-Life Adventures of AgileMan. Ideas I've had so far include:

• (Two Years of Going Agile)
• (Two Years of Lessons Learned)
• (Two Years of Agile Lessons Learned)

Anyone out there have any better suggestions?

The online prices at Lulu.com will be slightly higher than what I'm about to quote, but for in-person sales I'm expecting to charge $30 for the 2nd book and $45 for the collected edition (the latter of which is compared to $25 and $30, or $55 total, for the 2 books individually). For anyone in my neck of the woods who'd like to get a copy from the author himself on Launch Day (sometime in January 2009), please let me know now so that I can be sure to print enough copies!

While the actual writing of the books could at least conceivably be considered "work," I have to say that doing the various extras for them comes almost entirely under the category of "fun!" I had a great time dreaming up the comic strip captions that I used in The Real-Life Adventures of AgileMan (Lessons Learned in Going Agile), not to mention the minor thrill that I felt in creating the artwork in the first place! While I don't want to give too much away ahead of Launch Day '09, I will say that I'm having every bit as much fun this time around! I also tended to laugh out loud quite a bit as I came up with the contents of "AgileBoy's Glossary of Terms" for the 1st book, and I have an idea for something similar to use in the 2nd one. I really enjoy flexing my creative muscles on things like that, and if the people who buy the books get a kick out of them - as a few readers have told me they did - then all the better!

As for timing, the reviewers have until Nov 21st to get me their feedback (some of which has already come in) and then I hope to be starting the printing/publishing process shortly thereafter. I might manage to have the first print draft in my hands as early as the first week of December, if all of the stars line up and nothing goes wrong (I know: what are the chances?)

And that's where things stand today.

One Lecture Down, One To Go

So I gave my first of two November Agile-related university lectures today. This was for a 2nd year Computer Science class (I'd mistakenly thought it was a 1st year course but was happy to learn my mistake!) and the goal of the presentation was to introduce about 20 - 30 young minds to the notion of doing development in an Agile organization.

In the fifty minutes that I had available to me, I covered the following:

• Why do most software projects fail?
• Where did Agile come from?
• How are the Agile methodologies different than traditional (Waterfall) ones philosophically?
• How do Agile and Waterfall contrast each other more specifically?
• What does life in an Agile environment look like?
• Where might Waterfall be better, and where would Agile be more appropriate?

I was pleasantly surprised by how interested almost all of the students were in what I had to say, and I got a lot more questions at the end than I'd gotten the last time I did this dog-and-pony show. I asked how many of them think that, when they've graduated and are out in the work force, they'd enjoy working in an Agile company. As far as I could see, they were all nodding in response to that question (nodding in agreement, that is... not nodding off)!

I also put a push in for my former employer, telling them that they should all apply there when they graduate, if they want to stay and work in the same city where they attended university.

All in all, it was a very enjoyable and rewarding hour for me.

Information Radiators: Could They Help Save The World?

As I was riding my bicycle today (in 17 degrees Celsius weather, despite there being snow on the ground... in October!), I had a thought:

What if the most important metrics around Climate Change were in everybody's face on a daily basis, like gas prices are (just to use one example that I notice most people around me talk about all the time)?

To see what I mean, consider the following hypothetical (and possibly impractical) scenario. Imagine that the current level of carbon dioxide in our atmosphere (one of the many worrisome statistics that get bandied about in most environmental discussions these days) was being measured every day, and today's value showed up wherever you went. You start up a browser... there it is, up in the corner. You turn on your TV... each network displays it, translucently, like they do their logo or call sign. You go out shopping... and it's on the ever present LED displays, along with notices of sales and special discounts. In other words, it becomes as commonly-known to the general public as the price of gas, thanks to the use of an Information Radiator model.

If that were to come true, would people be more likely to not only change their own way of living but also make more of a point to push their elected officials to make systemic changes at the municipal, state/provincial and national levels? I don't know the answer, but it struck me as interesting thought.

Agile On Campus

While I continue to try to find some time to put material here relating to either of my two AgileMan books, I thought I should mention that I've now firmed up two November university lecture dates.

I'll be talking to a first year Computer Science class next week as I try to provide them with a very high level introduction to Agile. Then two weeks later my wife Vicki and I are taking on a third year Project Management CS class for an evening. She's going to cover some of the ways that project management shows up in areas other than software development, and I'm going to present some of the PM challenges that can come along in an Agile environment.

While it doesn't pay a lot (or anything), it's still fun to get out there and sing the praises (and lament the pitfalls) of Agile with a bunch of hungry young minds.

Welcome!

This is a new blog, called The Real-Life Adventures of AgileMan, which I hope to use in promoting and discussing my two AgileMan books. You can see the front cover of the first book along the right side of this blog, and you can click on that image if you'd like to read a preview of it or even order a copy from Lulu (for a mere $27.50 plus shipping).