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.

 

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.

 

 

 

 

 

 

 

 

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.

 

 

Where the Gorilla Looks, the Gorilla Goes

 

“I just don’t understand how we can be so far off schedule?” I was staring at the reality of the latest monthly progress review and trying to decide just how many floors the General Manager would blow through when he hit the ceiling on getting this news.

A voice echoed out of the dark corner of my barely illuminated office. “Just imagine how far behind schedule you’ll be next month.”

Wonderful, just what I needed at… was it really 9:00 pm? I grabbed my coat and hurriedly shoved my computer into its bag. “Not now, Hogarth, I need to get home.”

The 800 pound gorilla emerged from the shadows, his inky black fur blending with the darkness so that only his glinting eyes and brilliant white teeth showed clearly. “No problem, I’ll walk with you.”

I signed and pushed out of my office doing my best to ignore Hogarth.

“Tell you what,” he said as he lumbered behind me. “Do me one quick thing and I promise to not pester you for a week if it doesn’t change your view.”

I stopped and turned. “Fine, deal. What do you want?”

Hogarth pointed at the cube lined hallway in front of us. “I want you to walk down the middle of this aisle, without hitting anything.” Before I could tell him just how easy and stupid that sounded he held up a massive hand. “Oh, while you are walking this way, you must keep your eyes on that wall clock over there to the right. No matter what you can’t take your eyes away.”

” Seriously?” I rolled my eyes. “Fine, just remember, you promised not to bother…” WHAM!

After picking myself back up from the floor I looked to see who the heck had left one of the rolling file cabinets in the middle of the hall. Only problem was I was looking up at the side of a cube wall. I’d not only not stayed in the middle of the hall, I’d veered into one the side halls and then into the wall of the corner cube.

Hogarth offered me a hand up. “You knew where your goal was. What happened?”

I brushed away his hand and straightened my coat. “If I was allowed to look where I was going…”

“So you mean like checking your project status more than once a month?”

I really hate it when he’s right.

We Achieve Goals We Look At

How is making your goals like riding a horse?

Some time back I introduced you all to Peet, my horse. At the time Peet was helping Hogarth and I explore a point regarding too much focus on work being bad for you. Today Peet and Sky, my wife’s horse, are back to help us demonstrate why keeping the goal in sight is so very important. If you ride a motorcycle, you already know what I’m about to demonstrate.

About twenty years ago, my girlfriend (now wife) told me I had no business ever riding a motorcycle. She said something to the effect that I didn’t have the focus. Being an overly confident young man I naturally disagreed with her. I mean I was a guy, I could do anything right? Well luck, fortune, or fate prevented me from realizing my dream to own a BMW Touring bike. This was one of those times to be thankful for unanswered wishes.

About eight years ago I started riding. My wife got me into it and I am forever thankful. As I talk about in the Gorilla Robot blog, it gave me a sense of peace and relaxation I had been lacking. It wasn’t all wine and roses though. About three months after owning Peet I took my very first solo ride. When I came back from the ride I found my wife and asked her “You remember when we first met, you told me I should never ride a motorcycle?” To this she answered something to the effect of, “yes and you still shouldn’t”. I nodded to her and said “you’re right. If I can make an intelligent animal walk into a tree, I have no business on a motorcycle.”

What Peet demonstrated to me that day was the principle of “you go where you look.” In the opening  photo is another very real demonstration. When cutting cows (herding), if you don’t keep your eye (and the horses eye) on the cow, they will happily go where ever they want. If I were to have looked away (I did), then Sky would have (he did) and the cow would have run back to the heard (she did). 

When you drive a car, the car is amazingly forgiving. If you look off to the side of the road, you don’t immediately swerve. You will, given time, but the car is very forgiving. Horses and motorcycles are not if you lose focus, if you start looking at something on the side of the road, very soon you’ll end up on the side of the road. Your entire body shifts when you look and aligns to move in the direction you are looking. With horses and bikes you see this effect very easily.

And the principle applies to goals and objectives as well. My mind really made the connections this week, when I attended the Bay Agile Leadership Network. Dan Kimble of Resonance Executive Coaching came to speak on the topic of the Leadership Crisis in the Digital Age. Dan has done competitive motorbike racing and drew the example between where you go on a bike and where you go with your goals. Being a horseman (who once nearly rode his horse into a tree) I instantly saw what he meant.

Think back to high school and the English final. You know, that multi-page essay about some book that at the time you would have rather read anything but it? You had a whole month to do the project. Yet how many of us didn’t even put the first word down until the week it was due? And how many of you wrote the entire paper the night before?

When we don’t keep our goal in sight, we don’t reach our goal.

So what can we do?

Do One Thing

Back in 2013 I expounded on not Multi-Tasking. This is not just for your day to day work, it’s for your goals as well. Try not work on two life goals in the same week, neither will get the proper attention they deserve. Since you’ve already broken these goals down into tasks (you have, right?), just focus on one task at a time and if a week is like an agile sprint, and the goal the product, work on only one product at a time.

The Daily Goal Look

Let’s pull a page from the agile community and hold our very own daily standup. Every day a Scrum team gathers around the task board and go through the three question ceremony. When they do this, they are not just reviewing what happened yesterday and what they plan to do today. They are also focusing again on their goal. The backlog shows their goal for the Sprint and every day they are focusing back on that goal. When you only review program status once a week, that’s four business days (and a weekend) to get distracted and end up completely off track.

So every day, connect with your goals again. This can both be your current work goals (what you’ll do this week) and more importantly your purpose goals. This won’t take long, just five or ten minutes a day. Your purpose goals should be no more than five at any one time and you can only do so much work in a week so don’t overwhelm yourself. Just reconnect with your goals so you can get to them at the end of the ride instead of running into the wall.

Until next time…


Gorillas don’t procrastinate, people do

Photo courtesy of neeravbhatt - FlickrI hit Ctrl-S and closed the document with a sigh of satisfaction. Another task complete and with no small amount of satisfaction at the final outcome. I switched to my personal Kanban board. Clicking on the task box, I cheerfully moved it from “Doing” to “Done”.

“Awesome, so what’s next.” I moved my gaze over to my rank ordered backlog and looked at the task at the top of my list, ready to move it to my “Doing” column. My eyes took in the next task, “Oh…”

I looked at my watch. “You know, an early lunch might be nice today.”

“It’s only eleven o’clock, nothing’s open.” Hogarth, my personal gorilla conscience spoke up from the corner of my office.

“Oh, yes, well good point.” I looked at my calendar. “Well, I should probably prepare for my 1:00 meeting. It’s a pretty big affair after all.”

Hogarth nodded, “It is. Isn’t that what the purpose of that report you just moved to ‘Done’ was all about.”

“Yes, well another good point.” I snapped my fingers, “Today’s Thursday, that’s the day I spend thirty minutes reaching out to my network!”

Hogarth waved towards my computer, “pretty sure you have that on the kanban board as a lower priority already. You’re board is ordered on what’s most important, right?”

I glared at Hogarth this time. “You’re not helping.”

Happily munching on bit of the bamboo plant, he said “And you’re procrastinating.”

“What!” I half rose from my chair. “I am not, I just have a lot of important things to do. I can re-prioritize my kanban based on new data.”

Hogarth nodded again, “Yes you can. Are you going to re-prioritize this task like you have every day for the last six months?”

“Six months, don’t be absurd. I bet you a brand new bamboo plant that it has not been six months.”

Hogarth smiled, flashing me those brilliant white gorilla teeth. “Deal.”

I flipped back to my task board. “Let see, opening up the history on this task I created it June 1st. Hah! See it hasn’t been six month. It’s been… uh… eight.” I glared at Hogarth again. “You set me up!”

He nodded. “And you’re still procrastinating.”

 

The Road to Done is Paved With Good Intentions:

All right, who here has never procrastinated on a task, raise your hand. Right, no one, no one, wait you? Okay, Captain America, you don’t count you’re a comic book character. For the rest of us, procrastination is probably as common as the common cold. Fortunately, unlike the common cold, there is a cure for procrastination.

According to psychologist Professor Clarry Lay, a prominent writer on procrastination, procrastination occurs when there’s “a temporal gap between intended behavior and enacted behavior.” That is, procrastination is occurring when there’s a significant time period between when people intend to do a job, and when they actually do it.

So how do you tackle procrastination. I’ve got two techniques and one kick in the butt that I think will help.

Break It Down: “Class, the assignment is a twenty-page essay on the impact of the Spanish Inquisition on a country of your choices. The paper is due in six weeks.” The enormity of such task often  paralyzes us into inaction. We find all manner of excuses to not start.” It’s so big”. “I’ll never get it done in time”. “Twenty pages?” Our high school history essay was just the first of many enormous projects we would face in our adult lives. Twelve-month software  development windows, five-year new car designs, decades-long infrastructure improvements. And like the essay, projects typically start with that huge hairy, audacious goal that seems insurmountable.

Yes, as Lao Tzu said, “The journey of a thousand miles starts with a single step.” Projects run using agile principles have shown us that even the largest task can be broken down into a manageable chunk of work. Whatever you are working on, start dividing it into steps and keep dividing them until you have something workable.

Avoid the Blank Page: As a writer there is probably nothing I fear more than a blank, white page. As a project manager, starting a project with no plan and no schedule used to give me nearly the same level of fear. That was until I discovered the almighty power of “Save As”. Whether I’m starting a new piece of fiction or a new project, I never start with a blank page. After two decades in Silicon Valley, I’ve amassed a huge library of templates and examples. With these, even if the project I’m working on has no history and no processes to follow, I always have some template I can start from. The final product may not look even close to the original template. That doesn’t matter, I don’t see it as rework, I see it as a jumping off point. That veritable beach head from old World War II movies.

Just Do It™: Good old Nike and their iconic slogan. Sometimes mind tricks, decomposition and the best laid plans of mice and men still leave you staring into the maw of procrastination in gibbering fear. That’s the time when my wife likes to give me a shove and say “Cowboy up.” Sit down and just start doing it. Don’t think of excuses, don’t schedule it, just start doing it. Odds are pretty good you’re going to come up for air an hour later having accomplished a lot more than you thought possible.

 

What was that? I haven’t written a blog since June, I’m a fine one to talk? Yes, yes I am. I’m not perfect, I absolutely make mistakes.  It’s the very reason I started writing this blog in 2009. I’m okay with not being perfect and sharing those mistakes with the rest of you, in hopes you don’t have to cover the same ground I did.

So grab a not-blank page and get going, “done” is just the other side of “not done.”

Don’t blame the Gorilla, blame the you

I shot up from my chair so fast it skittered backwards headed for the wall of the conference room. I didn’t really notice though, I was so worked up at this point, I would probably have ignored a 7.0 earthquake. The blame game going around the table had gone on long enough and I was damn well going to put a stop to it here and now. I pointed at the projector screen and was getting ready to lay into the program team with a vengeance.

 

When the projector cut out and the room was plunged into near darkness…

 

It took a minute of pandemonium before someone got the lights turned on and attention turned to trying to get the projector back on.

 

“Did you check the bulb, maybe the bulb burned out.”

 

“I bet it over heated, it is hot in here.”

 

“Did your computer get unplugged? I do that all the time.”

 

“Are we having a power outage? No, right, we wouldn’t have lights.”

 

“Facilities can’t keep anything running around here, you really outta complain.”

 

The “help” from the rest of the program team was not doing anything of the kind. Finally I decided it was better to just call the meeting. No one was focused on the meeting anymore and without the projector we couldn’t work through the issues we were looking at.

 

As everyone filed out of the room, someone brushed the light switch plunging the room back into a gloom broken only be the light coming from the hallway. Apparently my laptop was now suffering the same malaise the projector was and its screen was black. Leaning on the table, I gave a long weary sigh. First the program drives off a cliff, quickly followed by most of the program team and now I’m being plagued by faulty equipment. What was causing all of this?

 

From deeper in the gloom of the conference room I heard a deep voice. It spoke quietly and I could just make out the words “circles” and “oneself.” I hung my head a little lower, great, just what I needed.

 

I stepped over to the doorway and flipped on the lights. “What do you want Hogarth? Can’t you tell I’m just a little busy right now to be dealing with a figment of my imagination. Unless you can solve my problems I’m not interested. You can’t tell me what cause the projector failure is, can you?”

 

My gorilla was lounging in one of the chairs nearer to the projector screen. His size umpteen big feet were propped up on the table and he gave me one of his casual Hogarth signature shrugs. “Oh, I don’t know. Have you ever thought it might be you?”

 

Looking at him as if he’d just grown a second head I said, “What on earth makes you think I’m the cause of the problem?!”

 

Hogarth pointed me at my chair, still pushed up against the wall where it had stopped after my abortive tirade. Down at the base of my chair, wrapped around one leg, was indeed the source of all the problems.

 

The power cord for the entire conference-room table. My chair had caught the cord and pulled it from the wall when I stood up.

 

“Oh, well dang…”

 

 

One Hundred Conversations With The Gorilla In Room

 

In November 2009 I had my first conversation with the “Gorilla In The Room” and began my ongoing journey to become a better program manager, leader and person. Ninety-eight conversations later I find myself looking back at my journey and asking myself what I can learn from all my conversations with Hogarth. What can I learn from how I managed my career differently, from how I helped others, from how I interacted with others, from the conferences I’ve spoken at and the people I’ve coached.

 

In June of 2011 I asked similar questions in “Wake Up and Smell The Gorilla.” Only at that time I was still focused my personal “branding.” I was trying to create solutions. “Wake Up” was my vehicle to talk about my five point value system, when I probably had no business in trying to change anyone else yet. Reading the blog again today I even see that Hogarth had already giving me the answer. I was just so absorbed in helping others, I was missing the real key.

 

“When searching for the source of a problem, start looking in ever widening concentric circles about oneself.”

Mark Horstman, Manager Tools      

 

Regular readers met Peet, my horse, back in “The Gorilla Robot.” Last year I also took up the sport of archery, an excellent sport for mental calm and mental concentration. While both my hobby of horse-back riding and my sport of archery were taken up for their enjoyment and for the positive impact they had on my stress levels, I have since learned an equally valuable lesson from these two past times.

 

What does this have to do with Mark Horstman’s quote?

 

~”I’ve never met a problem horse. I’ve met many problem owners.” Clinton Anderson, Horse Trainer

 

“Don’t blame the arrow, blame the archer.” Uncounted numbers of Archery Coaches

 

Whatever the problem you are facing, no matter who is involved, or what the mitigating factors are, you can almost be certain that some of that problem is because of you. An example…

 

Before I met my wife, I had the normal red-blooded American-male aspiration to own a motorcycle.  My wife had owned a motorcycle and was a really good rider. Not long after we met she told me I had no business riding a motorcycle, I just didn’t have the right mindset for it. Naturally I didn’t believe her for an instant. I would take the CHP Easy Rider safety course and I’d be a great motorcycle rider, there was nothing wrong with me. Clearly she was wrong. The only thing stopping me was time and money, motorcycles are expensive.

 

I’d owned my horse for about three months when I took my first solo ride. I came back from that ride and told my wife, “You’re right. I have no business riding a horse. If I can steer an intelligent animal into a tree, just think what I could do with a motorcycle?”

 

I was so bound an determined to own a motorcycle (I wanted one of those nice BMW touring bikes) that I refused to even consider if I was right for riding. I ignored that I might be the source of the problem. Taking up archery was an even greater example. There is so much that the archer can do wrong, that the few times it really is your equipment are so rare it just pays to assume it was you.

 

And even if this is the 1% of the time that you are not at all a factor in the problem, if you tackle the problem like you might be part of it, then you’re going to get a hell of a lot farther than if you are always looking for the source outside of you.

 

Assume you are the problem, be happy when you are not. If you focus on constantly making yourself better, then you will make the world around you better.

 

So as long as I’m not perfect, I’ll keep on having conversations with Hogarth. One hundred conversations down, and here’s to two hundred more conversations.

Gorilla Mail: You can have mailbox zero, and you should

I took a deep breath and plunged in. Wading through the tide I tried to stem the flow and get above the flood. I kept at it, hour after hour, in a relentless slog that seemed to have no end in sight. I tried to stay strong and see my way to the end. But I was weak, I couldn’t do it…

 

Rearing my head back I yelled into the darkness of my late-night office. “Augh!!….. I hate Email!”

 

“Then stop,” came a very unhelpful reply from across the room. My cries of anguish had awakened the sleeping Hogarth. My gorilla contemplated me sitting in the solitary glow of my computer monitor.

 

“Oh, yeah, easy for you to say. How many emails do you get a day, you’re a gorilla.” Two hours of trying to dig myself out of an email hole had not left me feeling like pleasant conversation.

 

Hogarth tisked at me. Reaching into the darkness he came back with something that I first thought was a large banana. Until he flipped back the case cover to reveal an oblong screen and a soft keyboard. “iBanana. I usually get a couple hundred emails a day.”

 

I blinked and tried to convince myself I was just dreaming. Until I realized that even in my worst nightmares I would never imagine this much email.Two days in a training class and my inbox looked like an LA rush hour on the Friday on a three-day weekend. How was I going to get through this backlog and on to my current emails?

 

“You don’t.”

 

Oh, right, my gorilla was still there, mocking my working g style. “What do you propose I do, delete it?”

 

Hogarth lumbered over to my desk, setting his banana-shaped tablet computer on the desk. Leaning into the light he said, “Deleting is certainly an option. If it is really urgent, most folks will follow up with you. You had a very good out of office message.” He probably saw my look of utter horror at these words. “If you have to go through them, then sort it all by subject and use the navigation approach.”

 

“Navigation approach,” I asked.

 

He nodded, “Yep, when you’re lost do you go back to where you started, or do you try and figure out how to get unlost from where you are now. You know, maybe by asking direction or something.”

 

Trying to ignore the ‘guys never ask for directions’ crack I said, “You figure out where you are now. It would be silly to go back to where you started.”

 

Hogarth nodded. “Bingo. So why do that with emails? Read the last one in the thread, figure it out from there.”

 

I gave a resigned shrug, his idea had some merit. It would certainly help with this massive backlog of email. “Okay, so that gets me out of the hole. Got any brilliant ideas on how to not get buried again?”

 

My gorilla gave a nod. “You’re of course familiar with Newton’s Third Law of Motion?” Hogarth asked.

 

I snorted, not seeing where this was going. “Oh course I am. ‘For every action there is an equal and opposite reaction”

 

He nodded his head, black fur shining in the desk lamp’s glow. “Close enough. Now what happens if you apply that to Parkinson’s Law?”

 

“Parkinson’s Law…” I cocked my head sideways. Desperately, I tried to see where my Gorilla’s logic was taking me. “Parkinson’s Law states ‘Work expands so as to fill the time available for its completion.”

 

Again Hogarth nodded. “Yes, and so the opposite would be?”

 

I blinked a few times, processing his question in my mind. “That’s so crazy it just might work…”

 

 

RULE YOUR INBOX, DON’T BE RULED BY IT

 

Parkinson’s Law is the concept that how ever much time you have to complete a task, you will fill that time. So what is the reverse of Parkinson’s Law?

 

Have you ever been in a situation like this:

Tomorrow you go on vacation. You absolutely have to get this report done, or you can’t go. Normally the report takes two days to compile. You dig in and manage to get it done by the end of the day. You really wanted to go on vacation.

 

If you’ve experienced something like this, then you’ve discovered the Horstman Corollary to Parkinson’s Law.

 

“Work contracts to fit into the time we GIVE it.”

 

If you spend all day in your email, then you’ll spend all day in your email. Parkinson has won. Email is dominating your life because you let it dominate your life. So don’t spend all day, just spend 30 minutes, three times a day.

 

I’ve heard of the Mailbox Zero concept many times over the years. I’ve have  even managed to get to there a couple of times, just never for very long. I just never saw how it could be possible. Like so many I believed it was some Sisyphean myth dangled by management consultants to make themselves more money.

 

For the last several years I was usually happy if I could get under 50 emails and to do even that was a struggle. My email was still killing me. It would backlog with tons of unread messages it felt like I was spending all day in my mailbox, constantly responding to the latest fires. That’s not to say my email habits in the last several years have not improved significantly. I learned a lot of great ideas from the Manager Tools 2005 podcast, Got Email?. Ideas like auto filing distribution list emails into folders,  flagging emails I’m only CC’d on so I know they are lower importance or scheduling my follow up as tasks or appointments. This all had helped, it just wasn’t enough.

 

Since late March, 2013, I’ve left work with an empty mailbox more than 90% of the time. Not just empty at the end of the day, empty in the morning, and empty after lunch. Following the advice from Manager Tools “Email Three Times a Day podcast” (Email Three Times A Day – Part 1, Email Three Times A Day – Part 2), I stopped letting Parkinson rule my life. I schedule time to read my email, even going so far as to setting a countdown timer. Thirty Minutes in the Morning, 30 minutes in the middle of the day and 15-30 at the end of the day. It wasn’t easy to start. With focus and perseverance though I was able to power through. And all the demons I was worried about never materialized.

 

  • People don’t complain that I’m late in responding to their emails
  • I rarely get trapped in email chains that go on forever and ever
  • I don’t forget to do things because they are not in my mailbox to remind me
  • I get to all my email (sometimes I still go more than thirty minutes, but I spend way less time that I used to)

 

 

Here are some additional tricks I’ve been using. Ones I adjusted from Manager Tools or came up with to meet the my usage of email as a program manager.

 

  1. Gone in 30 Seconds : The cardinal rule of Mailbox zero is “If it takes more than 30 seconds to process, then schedule it.” I use Trello for my task lists. If an email will take more than 30 seconds to resolve, I drop a task in Trello, file the email and move on.
  2. Emergency Skim: There are still people who live and die by email, not wanting to use any other medium to communicate and who expect quick responses. Some of these folks are above me in the management food chain, so I can’t change them (You don’t manage your boss, ever). Because of these people, I check my mailbox a couple of times between my main processing windows. However the rule here is you only process any urgent emails from those key critical people. You don’t read or process any other emails, even ones from those critical people. This requires good subject lines and some common sense. It does prevent you from living in your mailbox, without becoming completely out of touch. Using your smart phone to do this “Emergency Skim” is a great way to keep from getting in to deep.
  3. Action Folders: I have two sub-folders to my main inbox. They are called “To Follow Up” and “Waiting”

“To Follow Up” is where I put an email that requires a response and it will take more than a few seconds to type the response.  I still add a task to my task list. The email goes here so I can later come back and hit reply.

 

“Waiting” is where I put any email when I need more information to be able to act. This was one of the killers for me in the past. I’d keep emails in my mailbox because I was waiting for more instructions or input. Now I file them in “Waiting” and a couple of times a week I scroll through the folder. Most of the time I have already gotten the response I was waiting for and have acted already. These emails then just get filed or deleted. If I’m still waiting for information, then it goes in one of two buckets. If it is a task I need, I ping them again. If it was something the other party asked me to do, I leave it and wait for them to follow up. Anything older than a few weeks gets filed into a normal file.

 

 

What about a massive email backlog? I just got back from vacation and I’ve got a thousand emails! I can’t get through that in 30 minutes.

 

Nope, you can’t. So don’t. Here are some things you can do.

 

  • Before going on vacation, set expectations in your Out of Office. Instead of saying “I’ll get back to you” say “Please follow up with me when I am back in the office.”
  • As soon as you get back to work, move all the email backlog into a temporary folder. Only look at email that has come in from Midnight to now. You can then process the vacation backlog without it being in your main mailbox.
  • Sort the backlog by subject. Then read the most recent email in the thread (only the final email, don’t scroll through all the responses). If you can’t follow what’s going on, contact someone in the thread you trust and ask for a synopsis
  • Hold the backlog for a month. After you’ve skimmed it for those critical nuggets and asked for a synopsis on that 100 responses thread, then just leave the backlog. After a month, if no one has followed up with you, then it probably wasn’t important. Rename the folder Vacation_Mo_YR and archive it (or just delete it).

 

 

 

Email is a tool, we don’t let the hammer decide how we’ll build a house. Don’t let email decide how you will do your job.

Gorillas are often a matter of perspective

 

“What? Another three days?” I was gripping the phone so tight I think I may have cracked the handset. I tried to rein in my rising blood pressure and listen to the what the woman at the other end of the phone was saying. I pretty much failed. With blood still pounding in my ears I said, “Look, get it to me as fast as you can” and then hung up the phone.

 

I would have started pulling out my hair, had I had enough to pull out in the first place. Days like this make me think it’s the job that is leading to my hair loss. Lacking hair to tear out, I resorted to a more vocal approach for expressing my displeasure with the situation. 

 

Taking advantage of Hogarth denuding my fichus plant, I vented my frustration at the gorilla. “I swear I’ve seen lazy before, but I’ll be pickled if I’ve ever seen someone as lazy as Sue. What does it take to get a simple revision to the document out? It’s been a bloody flipping week already and she wants another three days? Doesn’t she realize what it’s like to be in my shoes? Has she no compassion?”

 

I was on a roll now. Nothing like a good vent to get you going. I was ready to rip into techpubs and not stop until I’d flattened every proverbial tree in the imaginary forest. I opened my mouth to launch a fresh diatribe towards Hogarth and stopped before the first word began to form. Hogarth was giving me that “look.”

 

“What?!” I said.

 

My gorilla laid down the denuded fichus branch and turned to face me properly. Sitting on his haunches, folded hands across his stomach  he looked nothing so much like a hairy version of Buddha preparing to impart his wisdom.  “See first to understand, then to be understood.”

 

I raised an eyebrow, “Seriously, you’re using that line?” He was quoting Stephen Covey at me, specifically Habit 5. “It’s not like I’m on a subway car with a perfect stranger, I’ve know Sue for years. What the heck is there to understand now?”

 

Hogarth just stared at me. For an entire minute he said nothing, he just stared at me. You ever been driving a little fast on the freeway and suddenly have a police officer come up from behind. You of course take your foot off the  gas as our heart rate rises. As the police car passes you, the officer gives you that look that tells you they know you were speeding and then they drive off. After that you drive exactly the speed limit the rest of the way home. Hogarth was giving me that kind of look.

 

Finally he spoke, “Sue was in a car accident two weeks ago, she broke both her legs and is on bed rest at home. She’s been cutting back on pain medication just so she can have a clear enough head to get some work done because she feels really bad about letting the team down.”

 

I just sat there feeling like the biggest rear end of a donkey there had ever been.

 

 

JUDGING WITHOUT PERSPECTIVE IS LIKE DRIVING WITHOUT SIGHT

 

Back in 2011I reviewedthe late Stephen Covey’s 7 Habits of a Highly Effective Person. One of the things I really enjoyed about his book, was the very personal stories he put into the book. These stories brought home the lessons he was imparting in a way that sterile examples just can’t give. The one that stays with me the most is his story on perspective. That someone with the vision and insight of Stephen Covey could fall into the perspective trap, and in such an embarrassingly dramatic way, just emphasizes how important keeping an open mind is. In Covey’s case he assumed the parent was a bad parent who was letting his kids run amok on the subway, when the reality is father and children had just left the hospital where they had watched their wife/mother die.

 

The old adage says you never truly understand a person until “you’ve walked a mile in their shoes.” Thing about these trite old sayings is they are usually founded on something.

 

  • Does your co-worker always copy their boss, your boss and anyone else vaguely related to the subject onto replies to your emails? Maybe they are not trying to get you in trouble, maybe they’ve been burned badly by a “he said, she said.” situation.
  • Has your direct started coming in late every day? Maybe he’s not lazy, perhaps his car died and he can’t afford to replace it so he’s taking the bus and is too embarrassed to say anything.
  • Does that developer insist on always doing everything herself and not sharing her work? Perhaps she got laid off from a previous job because someone else took credit for all of her work.

 

Are there lazy, shiftless, dishonest, immoral people in the world? Alas, the answer to this is very much yes. And if we always assume the worst, then we will very likely never get much  done.

 

Before we jump to conclusions, we need to ask ourselves some simple questions. Questions that are going to help us not come out looking like idiots or tyrants.

  • Is this normal behavior for them?
  • What would they gain from doing this supposedly mean thing to you?
  • Has anything changed in their lives recently?
  • Has the company re-orged, had management re-shuffle, or are projects at risk?

 

And if you think someone’s behavior is a little off, instead of assuming the worst you should instead communicate with that person. In the Hogarth story above, I didn’t ask for any information, instead I just complained. I could have asked what the delay was caused by, or even better asked if there is anything I could do.

 

At the end of the day, it really comes down to trust.

 

Will you trust your team to have the best intentions?

One Size fits all Gorilla? No more Telecommuting?

“Look, Eric, that’s just not the way we work here.” I was trying to go for my most fatherly voice with this. It was a touchy subject. “You’re an incredible engineer, you’re awesome with the rest of the team. And the mentoring you do is priceless.” I clasped my hands together and tapped the desk with them, “but at this company we just can’t have people marching to their own drummer. You need to adjust your work schedule. We have policies and procedures that apply to everyone and that means you need to be here in the office everyday, or you can’t work on the team…”

 

An hour later I leaned back in my chair with an exhausted sigh. Wow, I was wiped out. That kind of meeting never goes well. But it had to be done, policies are policies and if it’s good for the boss, it’s good for everyone. What’s that saying about “what’s good for the goose is good for the gander”?

 

My office door opened just then. I looked up, half expecting to see a tearful Eric back to plead his case. Instead the light beyond the door was all but blotted out by the broad shoulders of my personal gorilla, Hogarth.


“What do you want, Hogarth?” I wasn’t going to let him get to me this time. I’d been enforcing company policy and I’d done it nicely and professionally. He couldn’t get to me this time.

 

Hogarth ambled in, swinging forward on one arm as the other reached out towards me with something.  “I just came to make a delivery,” Hogarth said. “Here’s your T-Shirt for the company picnic.”  He handed me over a folded black shirt that looked  minuscule in his hands. When I took it from his gorilla-sized hands I found the shirt didn’t look all that much larger in my hands.

 

Holding it to me I glared at my gorilla, “Hogarth, this shirt wouldn’t fit a pygmy. I don’t think my shoulders will even fit through the arm holes.”


Hogarth gave a shrug, “What can I say, Marketing ordered a ‘one size fits most’ people. Guess you’ll just have to adjust yourself to fit…”

 

Ouch, hoisted on my own words. I really have to stop doing that.

 

 

GET TO YOUR DESK BEFORE THE TARDY BELL RINGS!

 

Yahoo CEO tells remote workers to report to the office (Huffington Post)

The recent news, that Yahoo’s CEO has ended telecommuting has started up a firestorm of fresh debate and exposed the coals of long smoldering arguments on the subject.  According to the articles, all telecommuting is ending. From the customer service rep, who works full time from home, to the engineer who works from home one day a week so he can save on that hundred mile commute.

 

The reasons CEO Mayer gives should sound familiar to agilists everywhere:

“Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. “

 

Sounds almost like Mrs. Mayer was reading out of the Agile Manifesto when she wrote her memo.

“The most efficient and effective method of  conveying information to and within a development  team is face-to-face conversation.”

 

Business people and developers must work together daily throughout the project.”

 

I’ve worked on both remote and local teams and I can’t argue with Mrs. Mayer’s general logic one bit. There is nothing that beats face to face conversation. All the best that technology can offer still only scratches the surface of replicating that face to face experience.

 

And yet I find myself agreeing with those that are up in arms about this policy.

 

1: Are we in prison? First and foremost it is a mandatory policy, no or very few exceptions will be given. This reminds me of the agile principle that sits right between the two Mrs. Mayer seems to be playing from.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

 

Give them the tools and the trust to get the job done. Yahoo’s move isn’t giving people the tools and trust. Instead its making a mandate that covers all teams, all projects, all people, all locations. Even universities and public K-12 education have realized that some students will thrive better with virtual learning, than with face to face. You don’t motivate teams by locking them in a room and feeding them pizza. At the end of the day, the room is still locked.

 

2: Everyone must work in the office, which office? In the Yahoo memo Mayer says ” From Sunnyvale to Santa Monica, Bangalore to Beijing…” Well let’s see here. Say I work in Customer Support and I live in Santa Monica. The head of Customer Support and the largest team are in Bangalore, in fact there are no other CS folks in Santa Monica. Does this mean I have to move to Bangalore? My job is very internally focused on Customer Support. Sure, there are advantages to being able to go to lunch with HR. At the end of the day though, I still am not seeing my team face to face.

 

We live in a global society now. With projects often having dozens if not hundreds of people involved, it is nearly impossible for everyone on the project to be co-located. Someone is always going to be working remote. What’s the difference between the remote engineer sitting in a sales office in Des Moines and a remote engineer sitting in his home office in Windsor Heights (a suburb of Des Moines)? In High Tech, it has become increasingly common for test organizations to be located in India or China. Is Yahoo going to relocate all these people to Sunnyvale so that they can be next to the engineers making the product they test?

 

3: Get the right people on the bus: I reviewed Jim Collins book, Good to Great, back in November of 2011. Mr. Collins makes a very compelling argument for getting the right people on your team, instead of getting the right skills on your team. The same concepts hold true in military special forces, where a team trains together long term and learns the skills they need for a new mission together, instead of bringing a new person in.

 

Say you find the most brilliant engineer for your project. Not only does she have all the skills you need, she fits great with your company culture and the team. You know she’d be a great asset. Only your offices are in San Francisco and New York. The engineer is in North Carolina and can’t move because she takes care of her ailing mother. Do you pass up on the engineer who gets a perfect 10 and instead hire the local engineer who gets a 6, just because he’s local?

 

 

Working co-located is great! – Don’t get me wrong. When I’ve had the luck of working with a team, all in one place, the effects are awesome. The issue here is like an army handing out size ten boots for everyone, because that’s the most common boot size needed. What happens to the guy who wears size 13, or the woman in the size 4s?

 

You do what is right for the team. You remember that your teams are not the entire company. You remember that one size never fits all.

 

Oh! – In small defense to Mrs. Mayer. For all of you remote workers who don’t want to use a webcam in your meetings?

 

Get over it. Working remote doesn’t mean you get to come to work in your pajamas. It means you have to work 200% harder to connect with your other co-workers. Video chat is here, it is real, it is now. Use it, or get your butt into the office.

 

One size won’t fit the Gorilla and it won’t fit your employees either. 

 

Hogarth and the Gorilla Talker