17 April 2010

The Secret Sauce Recipe to Agile Coaching

Someone recently asked me how to build a successful career as an Agile Coach. I have to admit that if we're measuring by levels of income, I may not be the best person to ask. I've had a ton of experience, but I'm not good at marketing, or business administration, and thus just recently have been able to bring my rates up to what I believe my skills and experience are worth.

That's the "fail fast" clause: Those who are still reading are looking for more than just financial success.

Things that haven't worked, business-wise, include the website, and Google Ads. I don't think most clients will buy something as expensive as a three-day course without first exploring the word-of-mouth network. The website provides details, but I doubt it attracted clients. And Google Ads are great, if you have a commodity to sell. I was selling my skills, experience, and unique perspective; not my ability to mimic my mentors.

Things that have helped most: Colleagues (the network), perhaps blogging (the free taste of the ice cream), and certainly delivering presentations and workshops at conferences. Come to think of it, almost all the work I had after Agile 2009 came from my talk at Agile 2009, directly or indirectly. 2009 was a very rough year for a lot of us, but I'm very glad I didn't cancel that trip to Chicago.

I really do feel that I've established a strong reputation, and a fulfilling practice, so, yeah--by my standards--I'm successful. And perhaps there's something in my "secret sauce" recipe that you can adapt.

Cultivate Real Experience

Knowledge and experience are very important, but there's no way to rush experience. I've tried to strike a balance between "immersive" coaching (where I'm with the team most of the time) and brief training engagements. That immersive coaching has given me deeper experiences than I would otherwise have.

This implies that you have to be patient with your career. Having lived in San Francisco during the peak dot-COM years, I remember the results of foolish desire for instant wealth. You could take a few marketing courses and get a few certifications, and if you have a pleasant personality you may make bags of cash for a while. Eventually that will catch up with you, though, unless you...

Continue to Learn

Take training (traditional and otherwise) in a variety of areas. Follow what truly interests you, even beyond the edges of Agile and Lean (yes, the world is, not surprisingly, much MUCH bigger than what could possibly fit into a two-day certification course).

For example, I recently took a beginning sign-language class (at Elisabeth Hendrickson's Agilistry!). What does that have to do with Agile, you ask? Nothing, directly. I didn't expect to be able to say more than "Hello, world" after the course, but I was able to hold a simple conversation (about how much I enjoyed my dinner) in a noisy restaurant. The "Where Are Your Keys?" learning techniques used were "Fascinating!" (inside joke). Hmmm...could those be applied to Agile techniques?

I've also been looking into "Non-violent Communication" to help me be a better coach(, husband, son, citizen...). If I see a team having serious trouble with communication issues, or even cultural issues, I would feel comfortable recommending some external NVC coaching (though the puppets may have to stay in their box).

Look for the common, foundational lessons, then find your own voice when you teach these. I'm not quite in the "Do what you love, and the money will follow" camp, because I'd be on a beach in Maui co-authoring Larry Niven's next Known Space novel. But you do need to find an arrangement where you can "love what you do, at least for now."

Build Your Network

I've always tried to work with people who are smarter than me. A sincere, humble approach attracts knowledge. Get to know the people in the community, be friendly--and low-maintenance--around those who return the friendship, and give some extra space to those who respond with arrogance or fear.

Also, I try to work only with those whom I truly trust. Perhaps my luckiest attribute is a well-honed BS-O-Meter. I've worked with people who had only their own best interest in mind, but only when I was rather desperate, or only if I would have the chance to work with someone else who was brilliant.

If the gig seems a bit odd (e.g., they're hiring only "well-known, trusted Agile coaches" then they ask you to take a drug test), then weigh your options carefully. I once got asked to travel to an exotic far-away country; and I was very excited about it, until I Googled the place and discovered that it was horribly dangerous for "Westerners" to travel the same route to the office twice in the same car. No regrets about saying "No thanks!" to that one. I had nothing else lined up, but it only took a few weeks to find something else (in Hollywood, no less!)

If you're lucky--one of your brilliant new Agile friends will be a good marketer. That's how I found most of my independent work in the "Agile" world: I know people who are much better marketers than I am, and I sub out to them.

There will be those who want you to succeed (like me), and those who will see you as a threat. There's plenty of work to be done in this industry, so I've never understood the folks who see me as a threat! The successful folks are often too busy to handle all their clients, and they're happy to send you out and take a percentage. It's a triple win! I'd have to be stupid to do anything to break that trust.

You can take work with someone who doesn't trust you, but be cautious: They've either been burned (and they may impose all manner of weird restrictions on you), or they believe people aren't inherently trustworthy (usually because they, themselves, aren't). I have a hard time trusting people who don't trust me. I work that into the contract.

Ah, that's a gem: Find a lawyer who speaks your language, and who believes in writing win-win contracts. If the client sends you a boilerplate contract full of "client has these rights, contractor waives these rights" language, ask your lawyer to review it, and to rewrite portions. A contract is meant to be mutually beneficial. Yes, you may end up paying the lawyer to improve the client's boilerplate contract. It's happened to me on three separate occasions. In all three occasions, the client thanked me and accepted the edits at face value. My lawyer also thanked me. Hey, at least it was a tax deduction. (And, if you ever sub to those clients, you can thank me, too.)

Be Fearless

I quip that I've made a career out of career-limiting moves (CLM's). Be willing to speak your mind (er...politely, if possible). If something seems wrong-headed, look to Martin Fowler's advice: "You can change your organisation [Fowler's British spelling], or you can change your organisation!" Be willing to look for greener pastures; but also be aware that the grass always looks greener over there. Instead of running at the first sign of trouble, you may have to roll up your sleeves and dig in to a problem to find a solution. Since I'm throwing all my worst cliches at you, you have to "know when to walk away, and know when to run." Face it now: If you're going to show folks a better way to do something, you're going to be working in some dysfunctional environments (with people who will sometimes hate you).

Follow Your Compass

Decide to do business ethically, then stick to that even when it hurts. You get to decide, to some degree, what collection of ethical business practices you choose to follow. The important points here are that you think about how to conduct yourself, and that you consciously notice when those ethical dilemmas are happening.

Don't expect that touting your ethics will bring you more business. Look at Google. When they did leave China, people reacted with the full spectrum of opinions: To some it was heroic; to others it was self-serving; and to yet others it was too little, too late. You cannot control how people external to the situation will perceive your actions. Don't make the choice based on a prediction of the impact on your reputation, and you will thereby develop a reputation as an honest businessperson. Paradoxical, eh?

Agile Is as Agile Does

I'm re-reading this after it's been stewing for months in the drafts "folder." I notice that I don't recommend one Agile practice, methodology, or principle over another. Yet this still seems like the right recipe for a professional Agile consultant.

What do I mean by that? I would suggest that if you neglect one of these, you do so at your own peril. There are sure to be ingredients I'm missing, but these seem like the key ingredients to a satisfying career. What will you add to spice it up? Write to me and let me know.

15 April 2010

Institutionalized Flexibility: An Impossible Dream?

My latest StickyMinds article on large-scale Agile transitions, and the impact of organizational culture, can be found here.

08 April 2010

Half-point planning cards?! "Khan!!!!!!!!!!!!!!"

I was looking at a burn-up chart spreadsheet recently, and (for some weird reason) started trying to add up the numbers by hand (iPhone calculator, actually). My suspicions were correct: Excel was adding incorrectly.

"InconCEIVable!" I shouted. Microsoft, make a mistake of this magnitude in an app? If Excel couldn't add, the entire US economy would probably collapse. (First sentence is sarcastic; but the 2nd is said with a straight face and a nervous twitch.)

Turns out, I wasn't viewing digits to the right of the decimal place. No matter what Alan Cooper might say about that, this was clearly my own "user error." (More sarcasm, by the way.)

The team had 1/2 point estimates on stories here and there, and that was throwing off my interpretation of Excel's display of the data.

I decided to ask the team why they were using 1/2 points. After all, story points are unit-less, so we could just multiply all estimates by two, and my brain would not have had to grok Excel's annoying user interface.

I wasn't asking them to change their estimation methods, or their existing estimates. It was instead a rhetorical question. Thankfully, they had grown used to my peculiar goal-less, blameless way of asking questions (which I stole from James Shore, the Walking Root-Cause Analysis Machine, by the way), and someone easily replied...

"Because the deck of Planning Poker(c) cards contains 1/2 point playing cards, so we used them."

My face twisted, turning bright red, and then it happened... "COHN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"

:-) It's not really Mike Cohn's fault. Well, okay, maybe it is, but big deal. I'm not really upset with Mike; it just makes for good blog post fodder. In other words, I do think there's something odd about 1/2-point estimates, and maybe something we can learn here.

Disclaimer: Also, Mike is a friend of a good friend (Hi, Bob!), and I think I've even friended Mr. Cohn on facebook (Uh, when did "friend" become a verb, anyway?) He's also a very smart guy, and has loads of very good Agile books published, and has those slick Mountain Goat Software Planning Poker(c) cards. Please, Mike, don't take it personally.

One does not want to get on Cohn's naughty list: He'll chase you "round the Moons of Nibia, and round the Antares Maelstrom, and round perdition's flames..."

But please, let's throw out the 1/2-point cards.

I like to suggest this method as one way to start estimation: By thinking of the smallest, simplest--but whole--bit of deliverable software that you could imagine building, and giving that 1 story point. So a 1/2 pointer is a strangely broken story, using that algebra.

Another way of looking at it, a 1-pointer is something you could get done in a couple hours.

Now, yes, I just mentioned time (bad, bad, bad...), which has little to do with Story Points, but a 1 equaling approximately 2 hours does not imply that a 2 is approximately 4 hours. After all, the margin of error in the conversion increases as the scale increases, and ya gotta go to lunch sometime! A 2 is simply twice as complex as a 1.

Why do I care so? Because removing the 1/2 pointer simplifies the math. Sure, adding 1/2 points is easy. But not adding them up is easier, and the team could keep a running total in their heads while they plan, for example. Save your brain's electrical current for things that matter, like Star Trek trivia. Not Excel's ridiculous user interface...