The not so secret ingredients of the Gorilla Coach Cookbook

Source: Wikimedia Commons

Source: Wikimedia Commons

“I don’t understand, it was a textbook implementation! I should have been able to do it with my eyes closed. ”

For once, I was talking to my gorilla willingly. Well not so much willingly. It was more I had no choice since the only other “person” in my home office was Hogarth. Of course, Hogarth didn’t seem to be listening. He was more intent on the garden just outside my window. I could almost see him cataloging the various plants. The long and hungry look he gave the ancient wisteria was troublesome.

Oblivious to this, I continued my rant. “I did exactly what they asked for, I executed letter perfect to the book. We had scrum rolled out to all twenty teams in record time. Heck, you couldn’t walk ten feet in their office without running into an information radiator.” Noticing Hogarth was not paying attention,  I turned to glare at him. “You’re not helping me at all!”

Hogarth reluctantly tore his gaze away from the garden view. “Why do you need me, like you said it was a textbook roll out. What do you think caused the failure?”

“What do I think?…” I stared at him open-mouthed. “If I knew I wouldn’t be talking to you now would I?”

Hogarth just kept looking at me.

“Fine!” I threw up my hands. “Let’s see. The first problem I noticed was the timebox kept getting broken.” I waved my hand at Hogarth, “That wasn’t it though, they actually had existing SLAs and agreements in place that supported interrupting the teams.”

“Existing processes you say?” said Hogarth. “How might you have learned about them?”

“I did learn about them!” I grumbled. “I just didn’t learn soon enough.”

Hogarth nodded. “Uh huh… Tell me what was it you wanted me to do again?”

Was he serious? “Damn it, Hogarth, I want you to listen to me. Just listen, don’t try and fix the problem. Don’t be the damned expert, just listen so I can work this out…”

My words trailed off to nothing. Hogarth had done it to me again.

 

You have to be agile to be successful in agile

Note: This blog is based on the article I had published on AgileConnections.com in January of this year. 

The problem with the classic playbook model is it follows a fairly standard set of steps. Sure, you might alter the timing a little, the overall process though is pretty much set down. No, it’s not as bad as that call center script the agent used on you last week. However, it can still lead to pretty upset customers as you try and roll out something that doesn’t work for them. “But I was just following the plan” isn’t going to save your engagement.

Even reaching all the way back into my project management days, I realize that I understood this unconsciously and managed to suppress that unconscious knowledge time and again in order to “follow the process” like I had been trained to do.

Perhaps it was my background in 1990’s era computer game technical support, where every customer’s problem was just a little different or just plain common sense that drove that not listened to, subconscious realization. It would take a decade of project management and a good five years of agile coaching before I came to the conscious understanding that it wasn’t the process, it was the ingredients.

Think of each customer like an episode of Iron Chef (America or the original Japan). Your judges (customers) are different every time. The live audience (additional stakeholders) will have a different energy. The secret ingredient (unique challenge) is always different. And your sous chefs (team) might even change from challenge to challenge.
What is almost always a constant though, is your pantry (tools) and basic kitchen appliances (core process frameworks). Having a strong mastery of these cooking basics allows you to assemble ingredients in unique ways and cook them to meet the needs of the customer.

What are my “Go To” ingredients and kitchen appliances, we all have them? Bobby Flay is going to reach for BBQ of some kind. If Michael Symon doesn’t use bacon at least once we think he’s ill and Mario Batali was sure to reach for some kind of pasta. You could also count on the blast chiller and ovens getting used in every episode.

So what do I always reach for?

Three ingredients and two appliances.

Three “Go To” Ingredients

Organization-wide education

Education is a key to any transition. I’ve learned that education normally needs to happen early, and it needs to be organization-wide for it to be most effective. If teams are trained differently on what agile means, it can lead to what essentially amounts to language barriers. Educating everyone at once leads to shared understanding and support. You can read my Agile Connections article for more on my Education First recommendations.

Observation phase

The principle here is “Do no harm.” When you first start an agile transformation, be it as a new hire or in a new project, you are almost always an outsider. You need to build trust before you can make a difference. The best way I’ve found to build relationships and trust is through asking questions and listening. Until you understand, you can not help guide change. I delve more into building team relationships in this Agile Connections article.

Engagement phase

This phase is what most people think of when they think of an agile transformation: the agile coach rolling up his sleeves and diving in to help individual teams. Doing hands-on facilitating with one-on-one coaching is a vital part of a transformation.

My key component for a successful agile transformation is to focus on one thing at a time. After engaging with the team, it’s typical to come away with a dozen observations as well as the team’s own reflections from their retrospectives. When faced with a huge list of things that can be “improved,” it can be very easy to start tackling it all, but you should fight that urge.

In agile, we coach teams to focus on one user story at a time, and it’s no different for improvements, impediments, and blockers. Start a team backlog for things the team wants to improve. Have them pick only one thing to work on at a time, and when they reach that goal, move the “story” down the backlog.

Two Key Appliances

Inspect and adapt cycle

One of the most underused agile tools is the retrospective. We tend to limit retrospectives to the team level, focusing only on the previous sprint. If you replace the tires on your car and ignore all other maintenance, it won’t matter how great those tires are—eventually, the car will stop running.

Retrospectives need to move beyond the team to the entire organization. You must apply the principles of continuous improvement to all levels of the organization on a constant basis.

And remember, inspect and adapt are two separate steps. We can be really great at finding problems, then do poorly on fixing them. Without the follow-through, inspection is pointless. You need to create an organization-level impediment backlog that is tracked and managed by the leadership team.

Assessment & Self-Supporting Metrics

People in any organization have a driving need to know how they are doing. In the case of an agile transformation, we always want to know two things: When will we be done, and is this agile thing working? To this end, metrics provide a vital service to the health and well-being of an organization and some kind of organizational assessment tool tells us if the transformation itself is being successful (You can be shipping tons of new value and still be failing).

With metrics, as I advocated in my previous blog, “Metrics: The third rail of agile adoption” you need to have interlocking metrics so you don’t fall afoul of Goodhart’s Law and have the teams gaming the system to satisfy leadership’s desire for some imposed goal. Using metrics responsibly is also vital. I give detailed advice on the responsible use of metrics in this article.

For organizational assessment, be consistent. If you measure one car in miles per gallon and the other in feet per second, you just end up confusing things. A common set of assessment tools allows everyone to track to the same understanding. I delve more into how to pick a good assessment strategy in this Agile Connections article.

The Cookbook doesn’t care about Frameworks

One thing I want to make sure to call out. Everything written here is totally agnostic of what frameworks or methodologies you are putting in place. Whether you are using Scrum or Kanban, SAFe or LESS, or whatever my go to things don’t change. Think of these frameworks and methodologies like the set of an Iron Chef. I don’t care if I’m in LA or New York, inside or outside. At the end of the day, I’m still going to reach for the same core ingredients and tools to roll out whatever agile framework is best for the customer.

Am I an Iron Agilist?

Okay, I have my “go to” ingredients and appliances, so what?  Plenty of challengers have faced the Iron Chefs with a “go to” approach and failed.  Am I winning any Iron Agiist competitions?

Well in one of my most recent agile transformations I have close to two years of data showing the before and after of their agile transformation. In a twenty team transformation, the overwhelming majority of teams saw thirty percent or more improvement in predictability, reduction in cycle time, and increase in velocity. They all also saw strong improvements in organizational maturity and happiness.

The biggest change always happened after education. After a team had gone through one of my two-day training, they always saw a marked improvement in their metrics.

Oh, one last thing. You know how every Iron Chef tries to use the Ice Cream maker and it almost always fails (trout ice cream anyone?). Be on the lookout for your agile ice cream maker. For the longest time, my ice cream maker was the C-Suite. I had to learn how to work with them to advance as an iron agilist.

 

Metrics: Third Rail of Agile Adoption

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

Just say “No” to Gorilla Debt in your Teams

By ccPixs.com

Debt Free by ccPixs.xom

You’d think with the amount of time I spend hitting my head on my desk it would have a permanent dent by now.

My most recent forehead abuse was brought short by the one thing I hated more than coaching a team that thought they we’re already perfect. The deep, rumbling bass of my personal gorilla cut through the sound of my head hitting the desk. “The SPFA called, they are filing a restraining order against you for furniture abuse.”

I blinked and looked up at the hulking form of my conscience in physical form. Why couldn’t I have a little cricket like Pinocchio? It would be so much easier to lock him in a jar and toss him in the ocean. “The SPFA?”

Hogarth  nodded, “Yep, the Society for the Prevention of Furniture Abuse. Their motto is ‘Desks Have Feelings Too’.”

“Go away Hogarth, I’m busy.”

Hogarth broke a branch off the nearest office plant and plopped into a chair next to my desk. “Pretty sure, destroy desk with forehead isn’t the most important thing on your backlog. What’s up?”

I sighed, he wasn’t going to go away so I might as well get this all over with. “The team didn’t take into account planned vacations and the product owner used their expected velocity to promise a feature to sales. Half the team was out and the other half was almost totally consumed by blocker bugs.”

Hogarth asked, “Didn’t they have this issue the last three months ago?” 

I nodded.

“And I seem to recall it was raised after the first sprint, over six months ago. Right?”

I nodded again.

“Well,” Hogarth said. “Sounds just like that problem you had with the original login server not being able to scale beyond 1000 simultaneous logins.”

“Don’t be silly, Hogarth”  I snapped. “You know very well we already fixed that issue two sprints ago.”

Hogarth was smiling, I hate it when he smiles like that, it usually means I’m about to be setup. “That’s right, we did didn’t we? How is it we took care of that?”

I didn’t know where he was taking this and I couldn’t just leave it alone, “We identified it as Technical Debt. We put it into the product backlog and worked with the product owner to prioritize it alongside new feature work.”

Hogarth nodded, “So we had  a problem with the product architecture, we recognized it and put it into a backlog with everything else to be prioritized?”

“Yes!” This was starting to get annoying since he was just reviewing what we all knew. Where was he going with this?

“So where is the backlog for the problems with the team? ” Hogarth asked.

Backlog for the team’s problems, like we do for Technical Debt?  Team Debt?

And he’d done it again…

 

Team Debt is just as destructive as Technical Debt

If you have any doubt that we are worried about the effects of Technical Debt, just Google the term. I get just over one million hits when I do. With the concept of agile development now considered in the mainstream, for software development if not all product development, the recognition that we can’t build our way out of technical problems with new features is taking firm hold. While how we approach it may still be an area of wide debate (TDD, BDD, dedicated legacy teams, rip and replace architecture, etc.) we are coming to a fundamental agreement that we need to slow down and deal with the problems we’ve created before we can speed up and build the next wave.

What about our teams though? It can be very easy to forget that agile is not just a new product lifecycle process (PLC). We have been so ingrained that PLC process is about what we are building that we often forget that agile is as much about “who” is building something as “what” we are building.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” –Principle 5  of the Agile Manifesto

Team Debt is the term I use to describe the impediments, issues and blockers that prevent the team from improving. Where testing and product usage will generally uncover your products Technical Debt, it is the Team Retrospectives, manager one-on-ones and coaching observations that will uncover the Team Debt. On the whole, something we are getting pretty good at doing in most agile organizations. Thanks to Scrum, we have built in the concept of the retrospective at the end of every sprint which gives us the mechanism to uncover our impediments.

Of course knowing the problem is only half the battle. We see this with Technical Debt all the time. Sure we know that our infrastructure can’t handle over a 1000 simultaneous logins, or that our core server has legacy code no one even remembers who wrote. We’ve known this for years and we’ve never done anything about it because we were too busy build the next new, wizbang, feature instead.

So just as we need to put Technical Debt into our product backlog and actually prioritize it to be fixed, we need to discover, track and address Team Debt.

The Impediment Backlog

Here, at AOL (Yes, AOL, they  are still around and doing cool stuff in 2016),  I’ve been experimenting with the concept of creating an Impediment Backlog. Just as the product has a backlog of everything we want to do with it, we need a backlog to track the issues impacting the teams. I’ve started coaching my teams to create an impediment backlog and include items from it into their Sprint Planning right alongside items from the Product Backlog. I’m also advocating for the creation of an Organization Impediment Backlog where we track cross and multi-team issues that cannot be solved at the team level.

By making the issues visible and putting them into the same formats as our Product Backlog, we can more easily understand and fit them into our day to day processes. If it looks like a duck, and we’re in the business of making ducks, then it will fit right in. If it looks like a fork and we’re in the business of making ducks then we’re likely to ignore it.

Ask me in a few months how we’re doing, it’s an experiment in the making.

How Agile Coaches are Like Vampires?

Dracula

By Screenshot from “Internet Archive” of the movie Dracula (1958)

For the love of!!!” I bit off my oath before it could move into not safe for work territory. Resisting the urge to slam the door I walked into my office. It had been another banner day in the world of agile coaching and I was ready to collapse into my chair so I could drown my sorrows in Facebook.

 

“Shhhh…. this is the best part”

I did a double take as I realized my chair, heck my entire desk was occupied. With his size gargantuan feet propped up on my desk, Hogarth the Gorilla was watching a video on my monitor screen.

“Hogarth, what the heck are you doing?” Only after speaking did I realize I probably didn’t want to know the answer.

“Watching a movie” he said. His hands were crossed over his chest so only his finger moved when he pointed to the screen and continued, “Bloody revenge of the Nosferatu Clan, awesome 1930’s era flick.” Turning his head towards me ever so slightly he then asked “How’d the coaching go today?”

“Huh, what?” I was thrown by his sudden change of conversation and quickly forgot all about his misuse of my computer as I recalled my day. Tossing myself into the guest chair I sighed, “Lousy, absolutely lousy.” I started ticking off my fingers. “One of the teams is in a tailspin after a disastrous planning meeting, to which I was not invited.” I ticked my second finger, “Another team can’t get anything done in a sprint and seems to think they don’t need to do retrospectives they just need to work harder, and they won’t listen to any of my advice.” I ticked a third finger, “I held a story splitting workshop for the scrum masters and product owners, only no one showed up. Too busy they say.” I started to raise a fourth finger when Hogarth raised a hand to stop me.

You know?,” Hogarth began. I knew this lead in. His next words were going to be some brilliant epiphany that even though I’d want to deny it, he’ d be right. I just sipped my coffee, waiting for the gorilla to drop.

“Agile coaches are really a lot like vampires.”

“What?” I spluttered coffee across the desk in my shock. There was no way this was some brilliant epiphany. Hogarth had finally cracked. “How on earth is my job like that of a blood sucking soulless demon? I am not an attorney!”

Hogarth waved to the monitor screen. On it the vampire was thrashing about in an open doorway unable to reach his intended victim who was only just inside the door. “Vampires have to be invited in.”

Invited in? Hogarth was relating me to an evil creature of the night and how it couldn’t cross the threshold of your home if you didn’t invite it. As long as you didn’t invite it, it was powerless to do anything.

Oh…

And once again, Hogarth had hit the crux of the issue.

 

How are Agile Coaches like Vampires?

  1. We have to be invited in.
  2. Our greatest power lies in influence.
  3. We need blood to survive.
  4. A stake through the heart destroys us.

We have to be invited in: Fans of 90’s era Buffy the Vampire Slayer will know this one very well. Vampires can’t cross the threshold of your home without your permission. So long as you don’t invite them in, they are stuck outside throwing taunts and jeers at you.

Whether you’re consulting or a full-time coach, if you don’t have an invitation you are not going to be effective. Something you learn in life coaching is that success requires something akin to a ‘rules of engagement’ with your client. You can’t just show up and start telling them what to do.  If your coaching client doesn’t want your help, or doesn’t want it in a certain way, no amount of talking or prodding is going to make you successful.

It’s the same thing for agile coaching. Even if the CEO personally hires you, and anoints you as the holy expert of agile, if you don’t get buy in from the teams, you won’t be effective at all. You can’t force yourself on the teams, you have to make yourself valuable to them. Start by asking questions, gathering feedback and observing what is happening with the teams. The act of doing this will help to build trust with your teams. You won’t be able to do anything without that trust.

Our greatest power lies in influence:  If you ever watched the 1990’s Dracula, with Gary Oldman and Keanu Reeves (You can be forgiven if you didn’t ), there was a big emphasis put on this aspect of a vampire’s power. And no wonder they have these power, when sunlight kills you, holy objects burn you and common garden herbs make you recoil, it’s hard to use the direct approach to get to your victims. So vampires use their mental powers to lure their victims into their deadly embrace.

Like the vampire, the agile coach can’t bull their way through a transformation. In order to be effective, they need to use personality and influence. We’re talking about “soft skills” here. You know, those things that have been made fun of for the last three decades, only suddenly now people are realizing they really matter (thanks to influencers like Sinek, Pink and Gladwell). The agile coach has needs to ask what the team think instead of trying to tell them. You have to let the team find the answer, not push it in their face.

We need blood to survive:  Okay, bit of a stretch so stay with me. Vampires need life force to survive. They get this through the blood of their victims.

Agile Coaches need energy as well, the energy of interaction. If we are locked away in a tower, with no interaction, we are not effective, we will fade away. If a motor is not used, it will stop working.  Having really smart coaches sitting in some central office, writing blogs, giving remote advice and the like is a waste of good assets and won’t make your teams better.

A stake through the heart destroys us:  Well, yeah wouldn’t a stake through the heart kill you too?

So yes, Agile Coaches are a lot like vampires. We need to look to be invited, we need to build trust with the teams, we need to be a light in the dark and we need to wear sunscreen outside.

Have you invited your agile coach in lately?

What kind of Agile Gorilla should I hire?

Snow PlowHint, the answer is yes…

“Arrrrgghhhh” I let my head fall to my desk with a resounding thud.  I let the momentum of the bounce  carry my head down again, and again, and again. Honestly I’m surprised my desk hasn’t broken with the number of times my head and it have come into repeated and violent contact.

I honestly don’t know how Don Quixote was able to tilt at all those windmills. After months of tilting at windmills I was utterly wiped out. It seemed every time I made a little progress, something would come along and drag me back into the quagmire of command and control  planning cycles.

“How on earth am I supposed to engineer an agile transformation when  no one in the organization even knows what agile is?” I muttered into the darkness of my office.

“That’s your problem” came a reply from out of that darkness.

I sighed. Just what I needed, as if trying to swim against the tide of anti-agile wasn’t enough, now I had to deal with my 800-pound gorilla conscience telling me just what I did wrong.

Looming out of the darkness, I could just make out Hogarth’s outline. “What now, Hogarth? Can’t you see I’m busy denting my desk?”

He gave a nod as he settled onto the edge of my desk. The desk gave a groan of protest, which Hogarth ignored instead producing a branch of bamboo from somewhere. The only bamboo I knew of in the office was in the CEO’s office and I cringed to think of what worse could happen to me if the CEO found out my gorilla ate his plant. “Relax” he said, waving the bamboo at me. “Bamboo plants over-night from Amazon prime.” He pointed at the spot where my head had been impacting the desk, “so problems with the agile transformation again?”

I leaned back with a sigh, “Yes,” I rubbed my face, “they know they want to go agile, but they haven’t the first clue what it is and every time I try and suggest something I get pigeonholed back into my little box. I can’t make any progress because they haven’t even gotten started. Resistance to change is high. I don’t know what to do.”

Hogarth shrugged, “not much now. It’s what should have been done before you even got here.”

I looked at him confused, “Huh?”

“Before you can pave the road, the path must first be found.”

I glared at my gorilla. He had a knack for pulling just the right quote from history to make his point and I’d been burned enough times by this that I was learning to ask before snapping. “Okay, who said that?”

“I did,” Hogarth said with a certain amount of smugness.

I blinked. He’d done it to me again. Just when I thought I had this whole invisible, conscience gorilla thing figured out he’d done it again. Then I stopped and blinked again. Realization dawned on me. He’d done it twice.

“The path must be found…” I muttered.

 

Should I hire an Agile Contractor, Agile Consultant, or Agile FTE Coach?

In my last blog, “To FTE or not to FTE” I looked at the Consultant, Contractor, FTE question from the point of view of the Agile Coach. Here I want to discuss it from the hiring company’s perspective. What are the pros and cons of hiring different types of agile coaches?

Full Time Agile Coach: A paid employee of the company, the Full Time Agile Coach is in for the long-haul. They are directly invested in the long-term well being of the company, often in the extremely measurable form of stocks and options. While still relatively uncommon, there are several notable companies using full-time coaches to help their scrum masters and scrum teams. As I write this I’m working  for AOL as one of four internal coaches. Salesforce.com has a large agile coach team to support its 1500 plus scrum teams. Other companies I know that have used full-time coaches at some point are Twitter, Lending Club, Fit Bit and General Electric.

Benefits of hiring a Full-Time Coach:  It is an oft stated truism that you are never truly done with an agile transformation. It’s an ongoing journey that never ends. And if your journey is never truly over, having a full-time coach means you have someone helping you no matter when or where you are in your journey. Think of it this way, when the Denver Broncos won the Superbowl, in Feb 2016, did they say “Oh we’re the best now, we don’t need our coaches anymore?” Not likely, while sports team coaching staff may change, what doesn’t change is the need for them. Having the full-time coach means you always have access to this critical resource. Something else you gain is organizational knowledge. There is only so much you can learn about a company in the common 30-90 day consulting arrangement. Your full time coach knows the people, the process, the history and where all the minefields are. They don’t have to “come up to speed” and have plenty of time to build strong relationships.

Downsides of hiring a Full-Time Coach:  The downside to a Full-Time coach is that being part of the system impacts their ability to effect large-scale change. Unless your agile coach is a vice-president or higher role, with a big army of directs, they rarely have the positional / role authority to make changes. This leaves them working from within the system on their influence power. This can slow down change and if you are just starting out, can make it very hard on the coach and the company. Often to the point of the transformations failing and the coach looking for a new job. When this happens, it is not usually not the coaches fault.

Consultant Agile Coach: The hired guns of the business world. The have deep expertise and a broad background of knowledge gleaned from many clients and past jobs. The consultant’s job is to come in, solve the problem and then ride off into the sunset while you murmur “who was that masked coach?”.

Benefits to hiring an Agile Consultant: They are the expert. You hire them because they have a deep well of knowledge on your problem. They know how to fix pretty much any problem you may have and thanks to the “hired gun” aura, they can actually get the problems fixed. Even the lowest tier consultant carries the authority equal to a director (a manager of managers) and often has the aura of authority to go all the way up to the CEO and direct what should be done. When you need something done and done fast, hiring a consultant is often the most expedient solution.

Downside of hiring an Agile Consultant: Eventually your hero-for-hire is going to leave. And that is usually a fixed schedule event. It’s the rare consultant who stays until the work is done (scope driven). So just like your average product release, they have a fixed schedule and way more features than they can ever hope to deliver. This requires the consultant to work fast to get everything done. And like in software, when you work under a pressure deadline, they will often end up sacrificing quality or documentation. When the consultant rides off into the sunset your implementation may be incomplete, have undetected flaws, still have organizational resistance or lack the education hand-off needed to sustain the change. I know of many agile transformations that were initial successes and then slid back into their old waterfall ways because they lacked a sustaining force.

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

The independent consultant is a sole proprietor business, sometimes with a support staff and sometimes not. They can also range from the small name shop up to a “named” agile thought leader. When you hire an independent you know you have their attention. If you hire one of the “names” you also get their specific expertise, which is often what everyone else bases their work on (If you hire Jeff Sutherland, you know you’ve got the expert on Scrum theory). However the Indie is also always going to be partially unfocused. They always have to be sourcing their next client. Even with a support staff, you often need the consultant to make sales calls to close deals. For the smaller independents, they can be a great choice for a small company getting started.

Hiring a “Firm” means you are often getting the combined knowledge of the whole organization. Even if only one coach shows up, that coach has the backing of their firm and can tap into the tribal knowledge.  Three of the most notable firms that fall into this category are SolutionsIQ, Leading Agile, LeanDog and Thoughtworks. Other Firms are more like a talent scout, finding really good independent talent and connecting them with the best fit. cPrime and Agile Transformations are a great example of this type as they work with many independent coaches, while also having an internal practice org that supports them.  Hiring a Firm comes with a lot of benefits on the engagement, however they can often be more expensive than the small indie coach. Though likely less expensive than one of the “named” independents.

Contractor Agile Coach: The hourly agile coach. Like the brilliant coffee aficionado, working behind the Starbucks counter, their knowledge and skills are often not seen or used because of the perception they are just a “temp” or the “hired help”.  Added to all the other issues, contractors have plenty of rules around them so that they never really one of your employees and rarely have support from a parent company like a consultant.

Benefits to hiring an Agile Coach Contractor: There isn’t. Companies that hire contractor coaches are losing out on nearly all the benefits of either the FTE or the Consultant. The only real value comes in the lower costs and being able to source them from contract firms (there are several that either specialize in agile or do a lot of agile business). However, you get what you pay for. While scrum masters as contractors works out okay, coaches as contractors is bad for the coach, bad for the business and I’m not aware of any successfully sustained successful transformations with a contractor coach.

Downside of hiring an Agile Coach Contractor: You get what you paid for. Contractors are usually considered “Staff Augmentation.” This puts them into the org structure like an FTE, only they generally end up at the bottom of the social and role power pecking order. Coaches need to have stability or authority to operate and get neither as a contractor. As Nancy Reagan used to say “Just say no.”

So… (Conclusion)

Let’s get the hard and fast out of the way. Never hire an agile coach as a contractor. While this is an excellent tactic for a Scrum Master, for an agile coach you are getting none of the benefits and all the of downsides possible. It may save you money and it may be easy. And you will get exactly what you pay for. Every company I’ve heard of, that tried to use contractor coaches to work an agile transformation, has not only failed to make any real change, they have burned through multiple coaches and gotten  a poor reputation in the agile community.

So then, Consultant or FTE Coach? 

Both…

My belief and recommendation is that for a successful agile transformation to take hold in an enterprise company, one must take a little from column A and a little from column B.

Start by hiring a good enterprise-class agile consulting company. Bring them in to help you find your path and get you on it. They will have the ability to overcome the institutional inertia and get the transformation rolling. Part of their transformation work though is to set you up for success once they have left. Before they leave they need to help you raise up an internal resource or bring in an external resource to carry on as your full-time coach.

The full-time coach (or coaches) will then carry forward using the inertia of the agile consulting firm. They will keep the transformation on the rails and act as the guides whenever things start to get lost.

By combining the authority change-agent power of the consultant, with the stable expertise of the full-time coach, you will greatly enhance the chances you will be successful in the long run.

 

 

 

 

 

 

 

 

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

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

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?

A Gorilla is more than the sum of its parts. So is Agile.

Car_Exploded _View_David_Wall_6999872214_93978664bc_z“Agile is failing, can you believe that, he actually said that to me?” 

You know you’re having a bad day when you willingly engage in a conversation with an 800 pound imaginary gorilla. I was striding down the hallway fairly vibrating with emotions. Hogarth lumbered along beside me uncharacteristically quiet. Which I guess should have been my first clue as to the rabbit hole I was being led down. 

“How can he say that?” I looked directly at Hogarth, “I mean we’re doing standups every day now. I even got them down to 30 minutes.” 

Hogarth finally chose to speak immediately making me wish he hadn’t, “What about the backlog?”

I threw my hands up “What about it? The backlog is being pulled straight from the PRD and we got the product manager to rank order them instead of the stupid P0 stuff. I mean how much more agile do you want us to get?”

Hogarth nodded sagely, or so I thought and I turned to walk into my office. Where I promptly stopped. 

“Hogarth, where’s my fichus?” The pot that held my latest incarnation of my favorite fichus was empty. Not just denuded of leaves and branches, empty. Even the dirt was gone. 

“Oh, that” Hogarth said. “Sorry, about that. I did replace it though. Here.” 

Hogarth reached under my conference table and started laying several objects on the table. A sack of dirt, a trunk, several loose branches and a sack of leaves. 

“Hogarth…. What’s that?” 

Hogarth smiled cheerfully at me. “Oh that’s your new Fichus. Well at least it’s all the parts to a fichus, you just need to put it together.” 

“HOGARTH!” I put up with a lot from my imaginary gorilla. His eating my plants wasn’t the end of the world, they made for a nice tax deduction. But this… This was going too far. “Do you think I’m some kind of Dr. Frankenstein? I can slap this all together with some glue, yell ‘IT’S ALIVE’ and suddenly I’ll have a fichus?”

I stared at Hogarth, my eyes blazing with a demand for an answer. 

Only no answer was forthcoming. Hogarth and retreated to the corner of the office and was sitting in his ‘happy budda’ pose with his hands clasped happily over his hairy belly. He just kept staring at me, as if he’d already answered me and was waiting for that inevitable moment when all the pieces would crash together making whole the monumental idiocy I’d…. 

Pieces… Made whole… Sigh…

Putting my head in my hands I said “and we’re so focused on doing the artifacts of agile we’re completely missing the spirit and purpose which would make it whole and successful ?” 

“Pretty much,” said Hogarth. 

 

A pile of parts does not Agile make

“We’re doing stand ups, we must be agile.” Admit it, how many times have you heard this? Honestly it’s grown to internet meme status and is one of the go too jokes for mocking a company that has failed to “get agile.”

That doesn’t mean it isn’t hitting the truth smack dab on the head.

Yes, the practices of agile are incredibly important. So is structuring your organization with interactive support from all tiers of the company. If you only do the motions though, you’ll end up with an organization that is a soulless automaton not unlike Frankenstein’s monster. The monster was “alive”, but lacked a purpose and drive, a soul if you will. It at least had the intelligence to know it lacked something and spent the story trying to find acceptance and love.

In some organizations they are just like the monster, in that they know what is missing, but their efforts to find the missing is stymied. This can be the teams own roadblocks or barriers imposed by the company or even external partners and customers. These organizations are almost sadder than those oblivious to what’s missing in their agile transformations. They know they are not getting what they should out of agile while being forced to go through the motions of agile every day.

The same cannot be said for all attempts at agile transformations. They muddle along doing the practice of agile, without the purpose of agile and they either gain minimal benefit from agile or fail completely. Often blaming agile they then fall back on whatever they were doing before because it has the comfort of familiarity. These organizations then face an even greater challenge in improving because “we tried it already and it didn’t work.”

An agile transformation is more than just predictability, stability, shipping early, or even transparency. Agile is a tool that can lead an organization from being extrinsically driven to intrinsically driven. From unengaged to fully engaged. From passive process following to active innovation creation. In short all those things we are hearing about from such modern luminaries as Steven Denning, Dan Pink, Eric Ries and past visionaries such as Peter Drucker, are things that an agile transformation can help with.

If you truly set out to do it and not just pick up a couple of pieces and expect to be able to have the value of the whole.

 

Gaining agile alignment, Gorilla style

right-238369_1280“Seriously?!” I was dumbstruck. How did this happen?

What I was looking at was nothing short than a monumental divergence of goals. The VP over the product group wanted to open up small satellite offices in several locations across the US. Granted, each location would be fully connected, high end telepresence rooms, live work space cameras all backed by a top-end online agile management tool. On the face of it, not the worst implementation for a distributed workforce using an agile development model. 

Only it was in direct contrast to what Jake had been working towards. He’d been working with facilities and they had a plan all in place to gut the development floor and rebuild it as a fully integrated team workspace. Pods for each team, quiet spaces, team dedicated meeting rooms with floor to ceiling white boards, the works. The perfect co-location workspace. 

Two wildly divergent plans. Yeah, they both were completely supportive of the company’s move to agile. The problem was they were pretty much diametrically opposite approaches.

“How on earth did I get here?” 

“Well, you got in your car this morning, got on the 280, headed south…” 

I looked up from my computer display to my unwanted visitor. Hogarth, my 800 pound imaginary gorilla and self-appointed conscience was leaning against the door to my office. He’d already reached over and stripped a branch from my latest fichus tree and was carefully plucking a leaf from it (Someday I’d figure out how an imaginary gorilla managed to cost me a fortune in real plants). 

“Hogarth, I’m not in the mood for your beat around the bush word games. If you have something to say, just spit it out.” In retrospect, telling a gorilla, imaginary or not, to spit probably wasn’t the best choice of words. 

Fortunately Hogarth didn’t take me up on the format of communication. Instead he quietly snacked on the fichus branch for a minute. “Well,” he said as he tossed the denuded branch to the side, “sounds to me like an alignment issue. The teams and management don’t have the same view on the why. The same order of values.” 

I gaped at him as if he’d suddenly grown a second head and it was speaking in Latin. “Look, everyone from the CEO down to the front line coders can recite the agile values and if they don’t know the principles by heart, we’ve got them on posters around the whole office.” I pointed to an example of such on the wall of my office. “So we are plenty aligned on what agile means.” 

Hogarth looked at the poster of the agile principles and cocked his head to the side, “Which one’s first?” 

I shook my head forcefully. “Are you crazy? They are all equally important. The Manifesto drafters didn’t number them.” 

“Oh, so they are all a P0 feature, I get it now.” Hogarth nodded with a satisfied smile. 

“Wait? What!?… No… I mean… Umm….” 

I really hate it when he does that.

 

The Agile Principles, they can’t all be Priority Zero

12_Legoman

How many of you have seen a classic Product Requirements Document (PRD, MRD) where the majority of the feature requests are priority zero or one? Yep, me too. It’s the job of one of twelve principles of agile “maximizing the work not done” to address just this problem. It’s part of what drives the creation of a rank ordered backlog. The backlog is one of the overarching “artifacts” of agile (and lean). You can be running sprints, doing Kanban pull, DAD, SAFe, LeSS, XP, etc and you will have a backlog. Few if any other “artifacts” have that kind of span.

And yet, we’re expected to hold all four agile values and twelve agile principles as equal?

Okay, yes, that would be awesome. A truly transcendent self-organized working group that has moved beyond the material concerns of today’s world.

Reality though tends to point out that having more than one priority is nearly impossible. Peter Drucker said something to the effect of “an effective executive can focus on one thing really well. An exceptional executive can focus on two.”

We rank order our product backlog. We even rank order things coming out of our retrospectives. And yet we don’t spend time aligning on the principles of agile? We can’t do twelve things at once, so what do we focus on first?

Agile Principles 20 / 20 Exercise

This simple exercise can quickly let a team, of up to twenty, rank order the agile principles from highest priority to high priority (recognizing that all the principles are important). By conducting the exercise across the company, you can quickly get a sense of priorities and where alignment is lacking. For example, I’ve found development teams often put “welcome changing requirements” very low on their list, while a product management or sales team might place this very high.

Understanding where alignment is lacking, will then allow the conversation to bring about that alignment. At the end of the day, Sales could end up realizing that development’s goal of “delivery working software frequently” is better than getting to make changes weekly. You have to have the knowledge, to have the conversation, to gain the alignment.

Exercise In a Nutshell: The exercise in two hundred words or less (152 to be precise).

Print each principle on a single sheet of paper. Find a bare piece of wall. A neutral facilitator then randomly shuffles the cards, placing “Our highest Priority” principle at the bottom of the deck. The facilitator places the first random principle on the wall and invites discussion. Then the second principle is held up and the team is invited to decide if it is more or less important than the first. This proceeds through eleven principles, with discussion as each one is placed (trust me, there will be a lot as more cards get on the wall).

When you get to “Our Highest Priority” explain that while the signers of the manifesto did not rank order the principles in general, they did put this one at the top of the list on purpose, feeling it to be the most important of equals. Challenge the team on if they feel it is also the most important.

For a complete walk through of the exercise, you can download it from my Dropbox share: Agile Principles 20 /20 Exercise.

I’ve also created a Pecha Kucha format presentation, which I’ve shared on Slideshare , under the name “Agile Principles 20-20 The Gorilla Coach

20-20-vision-v31-150x150Credit where credit is due. I learned this technique from the dual powerhouses of Jason Tanner (@JasonBTanner) and Luke Hohmann (@lukehohmann). Jason is a Certified Scrum Trainer and CEO at Applied Frameworks, a company that specializes in helping your company get its product direction and strategy going in the right direction. Luke is the founder and CEO of Conteneo Inc., well known for their Innovation Games which is now part of their larger Collaboration Cloud. I took a Certified Scrum Product Owner class co-taught by these two gentlemen and learned this exercise in their class, which uses Conteneo’s 20/20 collaboration game as a the framework.


How Gorillas Connect to Stakeholders

Photo by Danilo Rizzuti

Photo by Danilo Rizzuti

“I just don’t get it.” I was staring at the email thread on my screen. I was in utter disbelief as to what it was telling me. Like pulling on a single loose thread unravels a cartoon sweater, this one email thread had just unraveled three months of my hard work on the Jericho project. I felt like the walls were falling in on me and a part of me was hoping the building would collapse and crush me so I didn’t have to deal with the fallout.

Turning in my seat I stared out my window taking in the inky black of a moonless night. Jake’s email had started the thread innocently enough. He wanted to make sure we’d addressed the dependency with the data team before he started work. Donald’s reply pointed to a dependency with the release operations team and capabilities of that datacenter. This led to a ever growing cascade of dependency and communication issues that were culminating in a pretty simple message, the project was dead before it ever laid the first brick of its foundation.

“I just don’t understand”, I said to my reflection, in the window. “We planned everything, we reviewed the plan, we had buy in. What went wrong?”

A voice answered me from  the darkness of my office, “I believe the technical term is that the right hand didn’t know what the left hand was doing.”

Why did I ask a question? Didn’t I know exactly what would happen if I asked  rhetorical question?

“Of course you knew what would happen,” replied my 800 pound conscience. Hogarth reached his massive hand out of the darkens to turn on my desk side lamp. My office no longer lit by just my computer screen, I could clearly see Hogarth looming from the darkness of the rest of my office. Flashing me a blindingly white smile, he continued “Don’t feel bad, you know I would have answered even if you hadn’t talked out loud.”

I sighed. He was right of course. May as well just take the medicine and hope to get it over with. “Enlighten me, oh wise one.”

My gorilla wagged a baguette sized finger at me, “Now, now, I’m the sarcastic one here.” His other hand came into view with part of my fichus clutched in it. Nibbling on some leaves he said, “your problem is you didn’t tie off with your stakeholders right.”

“Seriously?!” I just stared at him. I had most definitely met with my key stakeholders. Heck, half of them I met before the project even started.

“Having coffee with Jake doesn’t count as meeting your stakeholder.” Hogarth scolded.

“Don’t start, Hogarth. I know how to talk with my stakeholders. I have relationships with all the key ones.”

He nodded his beach ball sized head. “Yes, you do. Let me ask you a question though. When the teams create user stories, is there a specific formula?”

I nodded.

“And when you do release planning, is there an agenda and set of questions you always ask?”

I nodded.

“And yet your meetings with the stakeholders are informal, not structured and not the same. How do you expect to know if  they are on the same page if you don’t ask them the same questions.”

Huh…

 

Ask the Same Questions, you will see Patterns

The Internal Customer Interview has been a staple tool in my project tool box for years. I first adapted it from Manager-Tools.com and over the years have  tweaked it and discovered its value beyond just when starting  a new job.

 

Now stakeholder meetings are nothing new. Even the Hogarth me knew to have meetings with the stakeholders. The secret to why the ICI tool works over standard relationship building meetings is in its consistency. If you don’t have consistency across your reviews, you’re not getting proper value out of your interviews.

 

Say you meet with ten stakeholders and with each of them you have a different agenda and questions, then you only gain the context of that stakeholder in that stakeholder’s domain.  You are less likely to pick up on trends that crossing the organization.

 

With the ICI format the key is to ask the exact same questions to each stakeholder. By asking the same questions, you can take the qualitative data of a single interview and begin to form a quantitative view of the whole through repeated asking of the same questions.

 

An interview shouldn’t be more than 30 minutes, so generally you want to limit yourself to five or six questions.

 

The Questions:

New Job / Major New Project:

These six questions are what I used when would start a new PMO job or major new PMO project.

1‐ What do you and your org need and expect from the PMO team?

2‐ What metrics do you use to assess us?

3‐ How have we done relative to your needs?

4‐ What’s your perception of our org in general, that perhaps the numbers don’t show?

5‐ What feedback and/or guidance do you have for me/my role/my team?

6- What are your biggest pain points?

Agile Stakeholders:

I developed these questions working for LeadingAgile. They are designed to evaluate where company is with its agile transformation (or preparing for an agile transformation). It extends beyond the recommended number of questions because of the sub-questions. It still fits into 30 minutes though, since the follow-up questions are generally shorter answers, so it still fits the model.

1- How well do you think <your company> is doing at establishing long-term, executable product vision?

2- How well do you think <your company> is doing at release planning (next 3 months) and making this plan transparent?

   2a- How well are you doing at meeting the commitments in the planned work?

   2b- Was new work added to the release plan after planning close and if yes, what percentage of overall backlog changed?

   2c- If yes to 2b, what percentage of new work was from farther down the existing backlog as opposed to brand new features/stories that did not exist when release planning closed

3- How well are you doing at delivering of working, “accepted” product to the end customer? Is it high quality, is it delivering value to the customer?

4- How well do you think <your company> recognizes problems and opportunities for improvement? With it’s Products (internal and external)? With it’s processes?

   4a- How well are you at executing on these opportunities for improvement?

5- Do you feel you are getting sufficient support to fulfill your  job role?

6- What are your biggest pain points in your job (or what keeps you awake at night).

Meeting Setup:

While the questions are the secret to a successful series of interviews, you need to make sure you set things up for that success.

Invitation: Contact each stakeholder individually. Request 30 minutes of their times to ask for them questions related to X (new job role, project, initiative). In the invitation include the one slide overview (see below) and a copy of the questions you will be asking. Never send this out as a broadcast message. Each person should be contacted individually.

One Slide Overview:  This isn’t a presentation. This is a focus for talking points. The contents are:

Mission Statement/ Goal Statement- What is being attempted?

How Statement (Optional)- It may be helpful to include how something is going to be done in some instances. For example the Goal focuses on improving predictability, and the How states this will be done through the rollout of agile governance (for example).

Plan– For a new job this is usually the 90 day plan. For a project or initiative this should be the next steps planning, not a detailed list. There should be no more than 5-6 bullets.

The Questions: Have them prepared before hand and let your stakeholders see them before you meet with them. For about half your audience, they won’t ever look at them. However the other half will look at them and be much better prepared to answer them in the interview because you gave them a chance to think about them before hand.

Stakeholder interviews are too important to go in off the cuff. Take some time to plan them and you’ll get a lot more value from them.