Category Archives: Coaching

Metrics: Third Rail of Agile Adoption

Posted on by
Reply

“Am I good or what?” The question was, of course, rhetorical, I was alone in my office. I

Photo Courtesy of: https://www.flickr.com/photos/bike/

Photo Courtesy of: https://www.flickr.com/photos/bike/

couldn’t help it though, I was pleased as punch and nothing was going to ruin my great mood.

“Or what?…”

Not even an 800-pound invisible gorilla.

“Go away, Hogarth, you can’t ruin my mood today. I’m on top of the world.”

Ignoring me, Hogarth ambled into my office. Spotting my new fichus, he plopped himself down and tore a branch from the tree. Around a mouthful of leaves, he asked: “So, agile adoption going well?”

His question instantly dispelled my annoyance at his assault on my plant. “Yes, yes it is.” I turned the monitor around so he could see. “Just look at these velocity trends! Every team is hitting or exceeding their velocity targets and we’re only three sprints in. It’s absolutely fantastic!”

Hogarth leaned in and intently studied the flat screen display. “Impressive. That’s got to be one of the fastest velocity growths I’ve ever seen. What did you do differently this time?”

“Hey, I’m just good. Awesome training, great coaching. Oh, and I bet the incentive program really helped out.”

Hogarth cocked his head to the side, “Incentive program?”

I leaned back smugly, “Oh, yeah. If the teams hit the velocity goals then they get a cash bonus and we’re going to hold a huge party at Humdingers Resort.”

Hogarth nodded, making some appreciative sounding grunts. I’d finally gotten to him. He was speechless.

After a long gaze at the monitor, he turned to me and gave one of his brilliant white smiles. “Sounds like a real Goodhart moment.”

It was my turn to cock my head in confusion. “A Goodhart moment?”

My gorilla nodded at me, “Uh huh. A well known British economist has an economic concept named after him. The layman’s version of Goodhart’s Law states, ‘When a measure becomes a target, it ceases to be a good measure.'”

I looked at Hogarth. I looked at the velocity reports. I looked at Hogarth. “You mean…”

He nodded, “Yup, those velocity metrics are about as useful as wheels on a speed boat. They look good spinning, but they are not really doing anything.”

 

Metrics- Can’t live with them, can’t live without them.

“Metrics are not bad, managers using metrics improperly is bad.” was a quote I sent out on Twitter (@JBC_GC) during Agile Open Northwest 2017. The session was “Why do metrics get a bad rap?” and it was a lively conversation with some surprising outcomes.

I’ve had a lot of success with the healthy use of team metrics. I’ve used the afore mentioned Goodhart’s Law as a conversation starter on the good use of metrics many times. And despite my success with team metrics I had never really articulated, to myself or others, what the disconnect between team metrics and management’s desire to set goals on those team metrics was. Turns out it is rather a simple thing.

Managers don’t actually care about metrics. They care about success.

Managers want to know if the product will ship on time or with the promised features or with the promised value, or all of the above. They end up using team metrics because it’s all they have. And in the classic square peg in a round hole scenario, they were hitting the square peg with the hammer to make it fit.

And how’s that worked out for us? Even in the well run agile project, the ability to tie team estimates and metrics to actual shipping dates is a highly mixed bag. We are horrible at estimating, to the point that the #NoEstimate movement is gaining traction through being right. This, however, is not a rant about how bad we are at estimating, using no estimates or even bad metrics. It is instead a look at what we can do about this disconnect between Team Metrics and Management need.

Step 1: Recognize managers need better forecasts, not better metrics.

Step 2: Stop using Team Metrics for forecasting.

Step 3: Give managers the tools to let them forecast.

 

Step 1: Recognize managers need better forecasts, not better metrics.

The best use of metrics is “as a lagging indicator of if we might want to talk to the team and see if they need help.” This is the coaching advice I give to management and teams, usually shortly after quoting Goodhart’s law. Metrics will not tell you when a team will get done without the risk that the metric will run afoul of the wisdom of Mr. Goodhart.

Just as you want to know if you should pack an umbrella tomorrow (or wear sunglasses, or get your snow blower ready), management wants to know if the project will be successful. A totally and perfectly valid request. Only you don’t use team metrics for this. Even when metrics are used as the source data, they are still being used to forecast. We look at velocity trends to estimate when a team will be done. That’s forecasting, not metrics.

Step 2: Stop using Team Metrics for forecasting:

Performance based on incentives doesn’t work. When we try and use metrics to drive performance we get Goodhart’s Law. The example I like to give comes from the book Freakanomics.

To summarize: India was having a problem with cobras. To address the problem the government came up with a great idea. They would give a bounty on every cobra head turned into the government. The program was a rousing success, just not in the way the government intended. People started raising cobras just so they could collect the bounty. In short order, India’s cobra problem was even larger than before the bounty was put in place.

If you tell a team they must make a March 15th release date. They will very likely hit that date or come really darn close. And then the company ends up dealing with bugs for the next five years. “When a measure becomes a target, the measure is no longer valid.” If you’re struggling to get your message heard, you might try showing them Dan Pink’s RSA Animate video to reinforce that knowledge skill teams don’t work best from incentives, they work best from Autonomy, Mastery, and Purpose.

Of course, not everyone is going to listen, even when they pay us for our advice.  Which is why I advocate limiting the metrics used and make them interlocking. Game one metric and the others will react in the negative. My four metrics are based on Jeff Sutherland’s three recommended metrics and a fourth I’ve had a lot of success with. They are:

  1. Cycle Time
  2. Escaped Defects
  3. Happiness Metrics
  4. Planned to Done Ratio

If you game cycle time so it’s really short, quality will almost certainly suffer. Let quality slip and you see an increase in cycle time and escaped defects. If planned to done is too high, then quality is probably suffering. And if metric 1, 2 and 4 are all really great and happiness is suffering then you have a strong indicator that you’re burning out your team.

Step 3: Give managers the tools to let them forecast.

This one is really easy. Stop reading my blog and go to FocusedObjectives.com. Troy Magennis has crossed the streams of mathematics, classic project management forecasting and agile to come up with a tool that allows managers to forecast when a team(s) or feature(s) will either be done or if it will hit the desired schedule.

 

I’ve seen this tool in action and heard stories from several users of Troy’s Forecasting approach. With this tool, the managers no longer need detailed metrics from the team. They can build forecasts based on as little as a half dozen data points, which can even be made up for initial forecasts. With just cycle time data points, you can run massive Monte Carlo simulations to get 80-90% accuracy on your forecasts (note, anyone who claims 100% accuracy is also gaming the system, or in denial).

 

So keep team metrics focused on improving the team. Give management their own tool for forecasting schedules and/or capacity. Then watch as the results of this is the teams getting, even more, work done, with greater predictability, and greater happiness.

The Gorilla asks: “To FTE or not FTE? That is the question.”

Posted on by
1

Or why I choose to be a full-time coach.Monkey-Yorick

“Explain to me again why we’re going to be renaming projects ‘missions’ and our teams are now ‘squadrons’?”

My boss waved his hand vaguely, “It’s the new consultants we brought in. Bunch awesome hot-shots. Their workshop was totally eye opening. I mean the military has been running fast projects for decades. Why didn’t we think of it sooner?”

‘Because we’re a data processing company with absolutely zero to do with the military’, I thought.

“Anyway,” he continued, “I think we should roll their recommendations out. You’re the coach, what do you think?”

What did I think? I tried to fathom the depths of his question and failing that I went with the obvious. “Well it’s hard for me to say. I didn’t go to the training so all I have is this promotional flyer you just handed me.”

My boss nodded gravely. “Yeah, that was unfortunate. But you’re a contractor so the company can’t send you to training.” He clapped his hands on the desk, and pushed himself to his feet. “Tell you what, spend some time Googling it and give me an assessment tomorrow. I’ve got to get to the strategy planning meeting.”

I started to open my mouth only to have my boss wave me to silence. “I know, I know. It would be so much easier if you could be in the meeting. Confidential company data and all though. I’ll brief you on what you need to know tomorrow.”

And with that he was gone, leaving me in his office staring at the flyer of some consultant, who I didn’t get to talk to, that I was supposed to give my opinion on how to implement. I buried my head in my hands and contemplated becoming a beat farmer.

“Hey,” the voice was deep and earthy “was that your boss I just saw walk into a conference room with those Fly Right Consultants?”

Oh my day couldn’t get any worse. Not only was my own personal gorilla here to torment me, he was telling me even the consultants get to go to the meeting I should be running. “Go away Hogarth, I’m not in the mood.” 

“Yeah well how do you think I feel. You try explaining to the security rhino why you need a security pass when you’re just the figment of a contractor’s imagination. You’d think a fellow hourly guy would have some sympathy for my plight.”

I hadn’t sufficiently tuned out Hogarth and what he said pierced into my brain, jumping me into action. “Holy …., I forgot to put in my time card!” I started to jump from my chair only to be stopped by Hogarth’s massive hand in front of my face.

“Don’t worry, I turned it in for you this morning?”

I blinked. “This morning! It’s 6:00 pm how can you know how many hours I worked today?”

Hogarth gave a dismissive shrug. “It’s not like that matters, you know they’ll only pay you for forty hours no matter how many you actually work.”

Not for the first time I came to the conclusion that being a contractor sucks.

 

Agile Contractor, Agile Consultant, Agile Coach, the continuum

There are several paths to becoming an agile coach (leader, champion, guru, insert your adjective of choice).  The most common path starts first with being a scrum master and then moving up into being an agile coach. A less common path is doing program management in an agile organization and moving from there into agile coaching.

What about once you are an agile coach? What then? How will you collect your paycheck? What is your place in the organization? As I see it, there are three paths one can take as an agile coach. Coach, Consultant, Contractor. Let’s review how these work, their pros and cons.

Full Time Agile Coach: A full time coach is perhaps the rarest form of agile employee you will find today (2016). While full-time scrum masters are not uncommon, the coach is more often a consultant or contractor with a sharply limited engagement. And I see this as a tragedy. The full-time coach is perhaps the most effective and cost-efficient solution a company will find.  Sure, being a full-time coach does not offer the short-term satisfaction that consulting does. What it does offer is stability, trust and the ability to make real changes.

Benefits of being a Full-Time Coach: Longevity and trust. As a full-time coach you are not under the tight time windows so often imposed on consultants. And being full-time means you have the time and position to build trust with your teams, manager and company. In a good company (life’s to short not to work for good companies) you have the time to get to know your teams and build up relationships and trust before you start getting into the deep work of agile coaching.

Downsides of being a Full-Time Coach:  You’re in the system. When you are inside of a company, reporting into the management structure and working within the politics, you lose a certain amount of authority and power. You can’t call on the “hero for hire” aura to push through your ideas. You may know the exact right thing that needs to be done. That’s great, now you have to convince  your management. It can be a frustratingly teeth gnashing feeling to know and not be able to do. You also have to get used to change moving slower. Your company isn’t losing you at the end of the contract and working hard to push everything through.

Consultant Agile Coach: As a consultant you can feel like one of the Magnificent Seven (either the Samurai or  Western version). You are hired for your specific expertise and when you come into an organization your word carries a voice of authority that can sway the course of CEOs much less the rank and file employee. You need to speak that authority fast though and you need to make it stick because you won’t be around for long.

Benefits to being an Agile Consultant: The “Expert” aura. Companies pay good money to hire consultants. Something about investing lot’s of money in you means you’re listened to; given access to people, meetings, and information; even given a certain amount of authority to make changes.  It’s a really big advantage. It is however pretty much your only advantage.  Yes, it is common for consultants to know a lot and have a deeper set of experiences than your average Full-Time or Contract Coach. This is not a benefit though, it’s just a recognition that currently the consultant space draws a high percentage of the top tier coaches. The other advantage of being a consultant is shared with contractors, that being “control of destiny”. A consultant, particularly the independent consultant, gets to pick and choose their clients and can choose to work or not work. A full time coach doesn’t get to say “I don’t like this team, I’m not working with them.” A consultant can do this (though if they do it too often they find their phone stops ringing).

Downside of being an Agile Consultant: The agile consultants are heroes, therefore they are expected to work miracles. The miracle they are usually expected to work is to make a difference in a vanishingly short time window. Ninety days in not an uncommon duration for a consulting engagement. Ninety days is a brutally short time window to get anything done in. In, The Ninety Day Gorilla, I talk about how a full time employee should practice the mantra “Do no harm” in their first ninety days. For a consultant the money often runs out by the time ninety days are up and if they haven’t made some kind of impact, they won’t be asked to come back again. Worse yet, the client will talk to their friends and those friends are no longer potential clients. If you can’t hit the ground running, cure world hunger, make the client happy, all in three months, consulting may not be for you.

Consultants also come in two major flavors, Independent and “Firm”.

The independent contractor is the ultimate in self-determination. They hang out their shingle on the power of their name alone. You hire that one person and bring them in for their expertise. If you’re lucky and wildly successful (Jeff Sutherland, Joe Justice, Mike Cohn) you can afford a staff to help you. Otherwise you are coach, bizdev, bookkeeper, scheduler and receptionist all in one.  You’re also always chasing the next paycheck. Even while helping profitable client A, you’re actively working to land client B, D and C.

“Firm” consultants work for a larger organization. In agile some of the big names are SolutionsIQ, Leading Agile, and Thoughtworks). Agency consultants have some more security than the independent and much more than the contractor. If you’re good, the firm will take care of you. You will probably get benefits, bonuses and a certain amount of immunity from the “what’s my next gig?” panic. You might even end up on “bench time” where you are being paid to do mostly nothing (write training, blogs, help with BizDev).

Contractor Agile Coach: Where as the Consultant is hired “hero”, a contractor can often feel like they were picked up at the local “Henchmens ‘r Us” outlet. A contractor is hired as an hourly employee that works within a company’s normal organizational structure. They are contracted through an outside agency who issues their paycheck and benefits (if applicable). They report to a manager within the company they are contracted to. Thanks to past legal cases, contracts are always for a fixed term so as to not ever imply the contractor is an actual employee. Depending on the company the max term usually ranges from twelve months to two years. Since this is not a fixed law, smaller companies tend to pay less attention to this and I’ve seen five plus year contractors at post startup, pre-IPO companies.

Benefits to being an Agile Coach Contractor: Honestly, not a lot. Like an independent consultant, the greatest benefit is you are in total control of your destiny. You interview with a “client” on your own merits. You decide when to work and when not to work. The advantage over independent consultant is that the contracting agency handles all the pesky paperwork for getting paid, benefits and the like. If you’re not ready to hang out your own shingle and don’t want to work for an established consulting firm, this is the greatest path of independence you can find.

Downside of being an Agile Coach Contractor: You’re getting the short end of the FTE and Consultant sticks. Contractors are considered “Staff Augmentation”, so they are treated as part of the organization they work for. They report to a company employee and are almost always the “junior” person in any department. Staff Augmentation means you don’t have the aura of being a hired “expert”.

And as a contractor you have the same fixed time window of a consultant. Last year I interviewed with one of the old enterprise players in Silicon Valley (you know the companies that were the big guns until Google and Facebook came along and Apple started their “i” wave of products). They were trying to engineer an end-to-end agile transformation of a core business unit. Only they were looking to hire an agile coach on a three month contract and expecting significant results in that three months.

So without the mantle of “expert” given to a consultant, a contractor has a doubly hard time being successful in the short time window given. That company I interviewed with last year is on something like their seventh agile coach contractor and no closer to real change than they were two years ago.
So… (Conclusion)

I’ve worked as a contractor, a consultant and a full time employee. While few would support contractor as the preferred way to earn a paycheck, the “Consultant or Full-Time” question is common.

For me the answer has become clear. I find it much more fulfilling to be a full-time coach. I’m not saying I won’t consult again in the future. What I am saying is that being a full-time coach I believe is the best combination of pros and cons of all the options.

Of course an even bigger question is what should companies hire?

You’ll have to wait until the next blog for that answer.

This blogs is a prequel to my upcoming Agile Coaches Playbook series. This blog is specifically inspired by my session at Agile Open Northern California on Oct 9 and 10. Special thanks to Mike Register, Sam Lipson, Ravi Tadlwaker, Arielle Mali, Eric Johnson, and Gautam Ramamurthy for their great contributions.

The Gorilla Pareto: Agile Adoption Anti-Pattern

Posted on by
3

80-20_TeamsIt seemed like a good idea at the time. That’s what I kept trying to tell myself and I dragged my way up the hallway to my office.

When the VP had come to my office and told me he wanted me to go help the Perseus team, kick off an agile transformation, I was thrilled. We’d been having some really good luck agile on the Icarus project and the VP wanted to see if we could extend that farther. The guys on Icarus we’re awesome, true rock stars all of them and I know that helped a lot. Still I saw no reason why the Perseus project couldn’t get some benefit from agile. 

I felt like a Spartan who came home without his shield. Not only did I fail, I was massacred. 

“You’ll be more motivated, more empowered,” I said. 

To which someone on the team replied, “We’re plenty motivated, we are doing the work we want to do.”

“The scrum master will be tasked with removing your impediments, making work easier,” I said. 

To which someone on the team replied, “If the company doesn’t fix blockers, then we work on something else.”

“You’ll be recognized for your expertise.” 

To which someone on the team replied, “So? We must be recognized, the company hired us. We gonna get paid more if we do agile?”

“You get to decide how its built, instead of being told.”

To which someone on the team replied, “Seriously? We don’t listen to product management anyway. We’ve been building it our way for years.”

“Status reports practically write themselves. The burn down is your status.”

To which someone on the team replied, “Project management writes the status reports. Besides, it’s not like anyone pays attention to them.” 

I slumped against the door to my office and gave a deep sigh. Of the entire team I think only one or two showed any real interest. One was a smart kid probably no more than three years out of his masters and the other was the overwhelmed and frustrated development manager. 

“Hey,” a voice called from inside my office. I looked in to see Hogarth abusing my office chair with his bulk. He was holding up the banana I’d picked up from the fruit bowl this morning. “You don’t have any Lady Finger bananas? Heck, even a Goldfinger or Lacatan would be great.” 

I strode into my office, extremely not in the mood to deal with my gorilla conscience today. “Hogarth, it’s a banana. You can have the yellow kind or the green kind that’s not good unless cooked.”

“Plantain” 

I stopped, “What?”

Hogarth got a professorial look, indicting a teaching moment was coming. “Plantain, that’s the green kind and not technically a banana. It’s Musa paradisiaca, while dessert bananas are Musa sapientum.” He held up the banana, “This Musa sapientum is a Cavendish, a Robusta to be precise. Your generic everyday banana. Okay for putting on cereal or peanut butter and banana sandwiches, just not the connoisseurs’ banana.”

“You’re telling me bananas come in more than big, little, green and yellow?” I asked. 

He nodded “Yeah, I think it’s like the parrot principle or something. Eighty percent of the bananas produced and exported are a variety of Cavendish.” He held up the banana by way of demonstrating. 

I blinked in confusion, “You mean the Pareto Principle?” 

Hogarth shrugged, “Yeah, that’s it. Some Italian economist right?” Hogarth cocked his head, “too bad they don’t have some Pareto rule for people.” 

Yeah too bad, that would explain a lot of things….

Hey, wait a minute!?! 
Why do some developers hate Agile? 

Note: The goal of this blog is to generate critical thinking on this subject, not to point fingers.

A lot of the popular agile marketing pumps up how much developers will love agile. How your development teams will be the ones fighting for it, championing for it or even doing it behind management’s back. Sure, I’ve met these people. Most of them work for boutique shops or start-ups. Unfortunately I find in enterprise software companies that these agile champions are often in the minority.

This has long created a cognitive dissonance in me. I know and understand in my soul that the values and principles of agile promote not only a more effective and productive workforce, it also produces happier, more engaged people. In short, I support agile because I think it will lead to a better world.

So why is there so much resistance from those it was intended to directly benefit? Then it hit me. I had a realization, an epiphany even. Agile is only revealing the underlying truth, one that many in the work force would love if it had never been undiscovered.

In Traditional Development, the majority of the work is being done by the minority of the people

The Pareto principle (also known as the 80–20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes. 

Anyone whose spent even a couple of years in high tech will have heard of the 80-20 rule. I hear it most often in the “80% of our calls are from 20% of our customers” or “80% of our business comes from 20% of our customers. Reaching to Wikipedia we find that the Pareto principle has several common business corollaries.

  • 80% of a company’s profits come from 20% of its customers
  • 80% of a company’s complaints come from 20% of its customers
  • 80% of a company’s profits come from 20% of the time its staff spend
  • 80% of a company’s sales come from 20% of its products
  • 80% of a company’s sales are made by 20% of its sales staff

    From <https://en.wikipedia.org/wiki/Pareto_principle#In_business>

Notice the one I bolded? Well yeah, I bolded it so you would.

What happens if you replace “sales” with “code” and “sales staff” with “development staff”, what do you get? The Pareto principle is arguing that 80% of the code developed is coming from 20% of your software development team. Those rock star coders? The ones management frets about what will happen when they leave? Yeah, they should worry. Because these rock starts are not just good at their job, Pareto argues they are probably doing much more work than the majority of the team.

Then along comes agile to shine a bright scary beacon on this reality. Suddenly bringing the coders into the light and making in crystal clear who is doing the work and who is not. When the team is reviewing work every day, and planning every week or two it quickly becomes apparent who is doing the work and who is not.

This is a tough subject and not likely to be wholly popular. No one wants to be told “hey, you’re a slacker!” I know, I’ve been exactly in the shoes of an agile resistor. I once told a room full of people “you’ll pry waterfall from my cold, dead hands.” And reflecting back now, I can say one of the things I feared was how much attention it would put on my own work.

So I can first hand the feeling of that scrutiny on your work is not unlike being a cockroach caught in the light. Close to twenty years ago I was in a job where I was doing okay, just okay. I wasn’t a rock star by any means. I was, however, the only person with a specific skill set and for a variety of reasons I didn’t work as hard as I could have. Then a new person came along. They knew my special skill set and tackled work with a wild abandon. The person was also incredibly nice and personable which meant it was hard to even dislike them. They were just doing their job and doing it well. I still felt like a cockroach caught in the open.

There are plenty of hard workers out there, that are not in the theoretical 20% of the people doing 80% of the work. And the painful fact is there are also a percentage of those workers who are knowingly under performing. The 2014 Gallup poll again found more than 15% of workers are actively disengaged in there jobs.

 

Want another interesting thought exercise? Let’s reach into the agile bag of data for a second. A common statistic you hear, agile proponents, is more than 60% of product features are used rarely or not at all. So if 80% of the work is done by 20% of the people and only 40% of features are ever used, does that mean our teams are 80% too big? I have seen some blogs of late that argue a super-star team of ten can build any product a team of 100 can and do it better and faster. Taking the Pareto principle into account, they may not be far off the mark.

What’s the call to action?

As I noted at the start of this section, I am not seeking to point fingers. I’m seeking to generate thought. I don’t have a call to action, I don’t have a solution.

I think I know a reason why some enterprise software coders are resistant to agile. However if they don’t want to be more productive, shining a bright light on them isn’t exactly going to make them happy.

I suppose we could use this data to convince executives to adopt agile more. If we can show them who are the real producers, they can either shrink their work force or hire more of the 20% who do the work. I’m not sure that’s going to be the best use of this data by an agile coach. It might be useful for agile consulting firms in their sales cycle.

As an agile coach, trying to find a way to encourage teams to adopt agile, it’s not immediately helpful. I’ve got a symptom now. What I don’t have is a cure.

How do we make everyone part of the 20%? Can we?

Ask not what your Gorilla can do for you

Posted on by
1

“Go away Hogarth…”

I knew it was him. I mean who else would loom in my doorway at 8:30 at night? Every sane person in the company had gone home hours ago.

“So what does that make you?”

Sigh… I really hate when he does that. Pushing back from my keyboard I looked across the dark office to where my gorilla stood. The few lights illuminating the hallway lit him in an eerie haze that made him almost ghost like in appearance. Given how he haunted my every move, it wasn’t that far from the truth.

“I’m not dead yet,” he said before he swung his arms forward to propel his body into the darkness of my office. I lost sight of him for a moment, as he moved out of the faint light cast through the door. And then there he was, his leathery muzzle poking into the light given off by my monitor and his teeth flashing as he offered up a toothy smile. “Though you’re not looking so great. When was the last time you saw the sun?”

“Very funny, Hogarth, I don’t have time for funny. I’m three chapters behind on our book. You do want to see this book published someday, right?” Looking at him, I gave a triumphant grin. I had him on this one. It’s not like I was toiling away on office work. I ‘d learned my lesson on that long ago. I was just taking advantage of the quiet of after hours office to get in some quality writing time (using my own laptop of course).

I could feel Hogarth’s eyes boring through me from the darkness beyond the monitor glow. As he spoke, his white canines sparkled in the light. “Those who can, do. Those who can’t, teach. Those who can and are good, do both.”

I blinked, “What? Seriously?” Okay, he’d gone to far this time. “I’ve done everything you’ve told me. I’ve gotten better at being a person, a project manager, a manager, a coach, you name it. I’m applying your lessons and things are going great here.”

He nodded, “Yep, you are. So why aren’t you at the agile coaching circle tonight?”

What the heck? “Are you smoking banana peels again? I’m not there because I’m here, writing. You’d think with you hanging around me, you wouldn’t have to ask. What on earth can anyone there teach me that you can’t?”

Hogarth leaned back into the darkness, his entire form become just a faint outline in the greater darkness of my office. “Who said anything about learning?”

Now I was really confused. And that usually meant he was about to hit me upside the head with some painful lesson. I’d gotten a lot better about seeing these coming. Only I didn’t know what it was, I only knew it was coming. “What?”

“Ask not what your country can do for you, ask what you can do for your country.”

Yep, he did it again… Oh, my head.

 

The Kennedy Approach to Being a Professional

Until recently I never really understood why I have become so passionate about helping others. I spent a long period of my career trying to stay below the radar. Don’t rock the boat, don’t stick out your head, don’t go the extra mile.

After Hogarth entered my life (See Wake up and Smell the Gorilla) , I found myself coming out of the bunkers and reaching out to help others. Even during the dark times, when I too was unemployed, I found myself reaching out to help others. I didn’t even think about it or when I did I was just thinking about my own karmic bank account. I was still early in my path and had much still to learn from Hogarth.

For the last year I’ve been regularly attending the Silicon Valley PMI Job Search breakfast. Why? I can hear many of you ask. After all I’m gainfully employed and am very happy with the job. Why would I be going to a breakfast for out of work project managers? For a long while, I thought I was just building my own network for a rainy day. I had a job, surely I can help others. The roles might be reversed someday and I’d need that persons help. Ultimately I thought I was doing it just to build up job karma for myself. It was all about me, right?

Then came the day I finally heard and understood what the facilitator had said many times before. Skip Le Fetrawas also employed and yet was devoting many hours a month to running the breakfast. Skip regularly said “I keep doing this because I get as much out of it as I do giving to it.” This took a while to sink into my head and it took another conversation for it to really gel.

We’d had a particularly intense meeting. One of the attendees had been facing some very specific challenges and the meeting had entered what I call “Group Coach” mode to help this one person. Now being a regular, and employed, I tend to be someone people turn to a lot, especially if Skip has to run off to a meeting. So on this day I had one of the attendees come to me. The attendee (We’ll call this attendee Pat) had something on their mind and needed to get it off. I was there to help. They said (I’ll paraphrase heavily), “This was a great session, X really needed it. I’m just curious, we did something like this for Y two weeks ago and while it really helped X and Y, I don’t feel like it is addressing everyone’s needs.”

I mentally rocked back on my heals on this one. Not so much by what Pat said. What got me was how everything was dropping into place as I formed my reply. I suddenly realized it wasn’t about building karma for myself. I suddenly realized why I help people and why it makes me feel so good.

Because it’s the right thing to do.

On that day I was Hogarth to Pat. President Kennedy’s speech came to my mind and the whole picture became clear. When I explained to Pat that what they should be getting out of the meeting is “what can I give to others.” As Skip had said for the last year, he learns and gets so much just from giving to the meeting.

Do it because it’s right, the rest will follow.

What can you do for your team?

Gorilla McPhee and the Groundhog

Posted on by
2

You know the nice thing about banging your head on the desk?

It feels so good when you stop…

And some days that is enough to look forward to. Days like today, launch day. The day we put our best face on and release into the wild the product we’d been working on for the last eighteen months.

You know the old joke about products? “Products don’t launch, they escape.” Well our product overpowered the prison guards and stole a tank to bust out. And I was left sitting in my office with that horrid déjà vu feeling of having done all of this before.

Because we had, on the last release.

The authentication database locked up after a hundred logins, just like last time. The servers couldn’t handle the traffic load of a major part of our user base logging in at the same time, just like last time. I could go on, only my head was getting sore and it really didn’t matter. Oh, sure, we’d improved the build process, getting down to twenty-four hours from build to completed tests. Other than that, though, we had made almost the exact same mistakes as last time and as certain as the sun comes up we would make most of them again.

This was all like some bad metaphor, I just wasn’t sure which one.

“Ground Hog Day”

“Wha?” I looked up to see Hogarth filling my doorway. “Hogarth, what do you need?”

My gorilla lumbered into the room and took a seat on the ground next to my fichus tree. With a contented sigh, he leaned back against the wall and helped himself to a branch from the fichus. Finally he looked up at me and said, “You were looking for a metaphor to describe your problem with déjà vu, I was suggesting Ground Hog Day.” He held up a finger, ” The movie not the actual day.” His teeth stripped a piece of bark from the fichus branch before he continued, “Every time Bill Murray went through his day, he learned something. Eventually he even started improving things.”

Hogarth gave a wave towards the hallway and the other offices. “Stop trying fix everything all at once, it won’t ever happen. Pick one thing, and fix it. Then repeat the process again and again.”

“Augh!!!” I threw my hands up in the air. Had I any real hair to speak of, I’d probably have been yanking it out of my head right then. “Am I ever going to be rid of you? Am I doomed to a life of moral correctness being delivered to me by an 800 pound gorilla?”

Hogarth folded his hands over his belly and gave me a soothing smile. “When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”

Oh no! I wasn’t going to be tricked this time. He’d made me look like an idiot too many times with his obscure historical quotes, “What famous philosopher said that?”

Hogarth smiled at me, “Nanny McPhee.”

“Huh?”

 

Coaches (Agile, Lean, Business) are like Nanny McPhee and Businesses are like the Ground Hog Day movie.

Last week I had the privilege to attend the SFAgile2012 “Unconference” in San Francisco. It was a great experience and I am still processing everything that I took in. In the coming weeks I hope to write about more of my observations and personal discoveries, like being caught in the middle of converging philosophies, the agile survival guide for functional managers, the need for a new definition of agile (who knew manifesto was such a highly charged word), or even a humorous look at the word fachidiot.

Right now though, I want to tie together two threads I experienced at SFAgile2012.

Hackerpenuer – or the Ground Hog Effect

The first was Joshua Kerievsky’s (@JoshuaKerievsky) closing keynote at the conference. One of the attendees recorded his keynote and I think it is very much worth watching. No matter what your preferred methodology is, I believe Josh’s points will resonate with you. And his use of the movie “Ground Hog” day to illustrate both the problems with learning and the benefits of learning from mistakes was superb. He extended the ongoing theme of the conference, that of the cultural hacker.

Part 1- http://youtu.be/29WekhL_c44  Part 2- http://youtu.be/_ArGvKpJI8k

His use of the movie was very telling and I can’t begin to cover everything. One of the powerful take aways I had was in the power of iteration. We watch as Phil relives the same day over and over again. We watch as someone is given the chance to “if you could do it all over again, would you do it differently.” Phil could, because his iterations were short and he remembered what happened the last time he was able to make changes and experiment.

What if your iteration is nine weeks long and you don’t do integration until week seven*? That means you have to go seven weeks between each time you get to effect a change. And then it’s a lot like the theory of reincarnation. Yes, you get to live life again, only you don’t remember the last  life, so you just might make the mistakes again.

*Yes, we know it’s a bad idea to wait so long for integration testing. It works for this example though.

What’s our Goal? – Mission – Values – Purpose

The second thread was one that I was unable to put words to during the conference. It was not until after, when reading Olaf Lewitz’s (@olaflewitz) Twitter profile, that I was able to put words to the thread. Even now, I find myself struggling with words I am happy with. For now, our Goal through Mission, Value, Purpose (MVP, yes I planned that) will have to do.

Olaf’s Twitter profile reads: “Linchpin. @agile42 Coach. When you need me, but do not want me, I must stay. When you want me, but no longer need me, then I have to go. (NannyMcPhee)”

Nanny McPhee is another movie, one in which Emma Thompson plays a character much like Mary Poppins. If you remove all the sugar and spice and everything nice and replace it with warts and boils and in your face honesty. McPhee could be the living embodiment of what happens when an organization embraces Agile/Lean methods. It is often said that Agile is a great tool for revealing the warts in your organization. And for those that stick with it, they find that the warts are not really that big  compared to the beauty of effectiveness they can achieve.

Nanny McPhee is also the perfect coach. She doesn’t try and change you. She creates opportunities for you to see change, she asks you the questions you are asking yourself, and she helps you to see the change you want to make. She doesn’t lead a horse to water, she asks the horse “Where is the water?” (After sneaking up on the horse in his stall and apologizing that the door was open.)

This brings to the interesting question. One I am still not sure I can even put properly into words. For want of something I’ll just settle for “Who are we, what do we do, what is our purpose (Hmm WWW. I think MVP is better). Really though I think the right question is, “What is my goal?”

We already have an idea of Olaf’s purpose through his espousing the McPhee mantra.

Simon Marcus, the CTO of The Library Corporation, summed it up as “Continuous learning and respect for others.”

Joshua Kerievsky’s (@JoshuaKerievsky), following his Hackerpenuer theme has “Hacking, Hutzpah, Happiness, Hustle, and Health.” (Yes, he hacked Chutzpah to make it work).

Illan Goldstein (@iagile), an Asutralian Agilist, responded to my own goal statement with “To constantly improve and to never go backwards.”

Which brings me to my goal. What is one sentence I can use to sum up my goal as a program manager, coach, facilitator, <insert title here>? For me, I say “My goal is to spend every day trying to make myself obsolete.”

This is not my personal life goal (my wife would object). This is my goal in working with teams and a company. After a twittersation (conversaion on twitter) with  @iagile and some others, I realize that even something so simple can lead to confusion. Words are amazing.

My thoughts are that if I am always trying to make myself obsolete for my current team/org, then I am working to better myself, better the team, empower the team and improve the value stream. It is almost certainly an unattainable goal and I think that is just fine. It is not the goal that matters, it is the journey that matters.

So with two popular moves, we see answers to change, the value of short iterations, the value of revealing the warts, and some clues to what is our purpose as coaches.

 

> I will always strive to not be needed. If I ever am not needed, I will be filled with joy and contentment for the world will surely be a much better place. <

 

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

The Gorilla Coach: A book review of Coaching Agile Teams, by Lyssa Adkins

Posted on by
2

Coachin Agile Teams

 

“You’ve got to do something! We can’t keep going like this, the entire project is going to collapse in on itself.”
Eric certainly had a way of getting my attention. I had instant visions of red project dashboards and burn down charts flat lining like a patient in the ER. Eric was one of the canaries on the project. There are always those certain team members that reflect the state of the project or are the first to see a major issue. Like the miner’s canary of old, they are the first to notice or raise the issues and a smart manager learns to pay attention. These are not to be mistaken for the Chicken Littles, who can give a hypochondriac a run for their money. When a canary sings, you listen to their song.
I held up my hands and spoke in a calm tone. “Okay, Eric, calm down and tell me what the problem is. I’m sure we can get this addressed.”
Eric took a deep breath and paused for a moment, as if suddenly unsure he wanted to continue. I gave him my best supporting smile and waited.  Finally finding his voice he said, “It’s Greg, he smells.”
I blinked. “Smells?”
Eric nodded, perhaps a bit too energetically. “No one wants to pair program with him. Heck no one wants to be within six feet of him. It’s like a mouse crawled into his shirt and died. Given the last time he changed his shirt it could well have.”
I sat back in my chair, a frown threatening to crease my brow. “This can’t be happening to me,” I thought. My next thought was to look across the table again. If Brenda were sitting there, this would have been another “The sky is falling” moments and I could have dealt with that like all the other times the sky didn’t really fall. Only this was Eric, the most reliable barometer of the teams health available. It meant that either Eric had gone off the deep end or the problem was very real.
So now what? This wasn’t a slipped schedule, we didn’t have a shortage of test machines,  it wasn’t even the completely useless requirements or product manager owner was foisting on us. No, I was being asked to deal with someone’s smell.”
They didn’t cover this in project management training…
“What would coach do?”
I turned to cast a baleful look at Hogarth.
“This isn’t a football game.”
My gorilla gave a little nod. “Good thing too, cause you stink at football.”
“Hogarth you are not helping me solve this problem.”
He nodded again, a brilliant white smile splitting his face. “Nope, I’m not and you shouldn’t be either. Solving Eric’s problem isn’t going to help him solve it in the future, now is it?”
Dang… he was right.
BOOK REVIEW: COACHING AGILE TEAMS, By Lyssa Adkins
Summary:
This book had been recommended to me many times, by many people. It forms one of the core study books for PMI’s new agile certification and you’d be hard pressed to find a conversation on agile coaching that doesn’t reference this book or the author.
Like me, Lyssa Adkins is a recovering command and control project manager and this is one of the things that makes this book resonate for me. While many agile authors have always been on the revolutionary/evolutionary end of the innovation scale, Lyssa had worked in the trenches of traditional projects and speaks to all audiences. Whether you are an eccentric software coder, turned agile visionary, or a former art major, turned project manager, turned aspiring agile coach, this book will speak to you. Very importantly, it speaks right to project managers “in transition.” Based on the traditional roles that project managers have filled, the scrum master role often ends up being a place project managers end up gravitating to as they journey into agile (or are shoved feet first by events, company, etc.) so this book is a great asset to them.
With 302 practical pages of content, there is a lot to absorb. It is not an evening’s light reading. Some of the concepts and mental challenges they raised had me setting the book down so I could process. All in all, it took me several weeks to read the book as there was so much to absorb and my mind wasn’t ready for it all at once.  But there was no way I was not going to finish this book.
The book is broadly laid out into three sections and the first hint you have on what it takes to be a good coach is that two of the three sections have to do with you.
  • It Starts With You: Starting with the obvious “will I be a good coach?” question, this section lays down the ground work to open yourself up to what is needed for you to be a good coach. Along the way it teaches you a lot about yourself.
  • Helping the Team Get More for Themselves: This section covers six aspects of being an agile coach, from the high level mentor concepts to the details of how a coach can help resolve conflict in a team.
  • Getting More for Yourself: One of the things I truly appreciate about agile, is its stance on failure. Lyssa’s book is no different and this section tackles head on the mistakes you will make and that it is okay to make them as long as you learn from them. It touches on the journey and knowing when you finally get there (Hint- you never do).
The Good:
Approachable Style: Lyssa writes this book in a conversational tone and weaves in direct experience throughout the book. You constantly have a strong sense that she is speaking from her own hands-on experience and her light style makes absorbing the deep content a lot easier.
Failure is okay: She knows that the journey to being a coach is going to have its bumps and bruises and she makes that okay. Instead of feeling like you are facing an insurmountable journey to be an agile coach, she reassures you that the potholes are just part of the journey. The most wonderful experiences are not found in the well manicured aisles of a department store, they are found out in the wilds of the world.
Lots of practical tips: The book isn’t just theory and platitudes. She provides solid tips, actions and exercises. She also provides tailoring to help you deal with all aspects of an agile organization, not just the agile development team.
The Not So:
No punches pulled: This could arguably be in the good things, you just need to be aware about it. Lyssa doesn’t pull punches and she’s not going to white wash this. If you are not ready to let go of your control freak nature, this book will be hard to read. You’ll put it down more than once and walk away. You will also learn really fast if you really want to be an agile coach. It is not a job for everyone. I still want to be one, but this book certainly tested my mettle.
Broad base may not appeal: If you are a hardcore scrum master, who is totally focused in on the artifacts of scrum and only scrum, you may find this book to broad for your tastes. Lyssa comes off fairly agile agnostic. This book is about helping any team, in an agile way, and this may not be pure scrum enough for some. Again, this could be argued as a good thing. I would hazard a guess that is part of why it ended up on the PMI reading list.
The Bookshelf Index: (Where does this book when I am done reading it?)
In my computer bag: This book speaks so much to what I want to be and how I want to engage with teams that it has not left my computer bag since I started reading it. It has quickly become a well worn copy and I will continue to refer to it regularly for some time to come.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP