Tuesday, June 5, 2012

The Gorilla always sits in the front row

I stuck my head into the room to cast a quick glance around. The presentations wouldn't start for another hour and the room was empty of all save some facilities people setting up the AV. Smiling, I ducked through the doorway and made for the best seat in the house. The middle of the back row.
I merrily pulled out my laptop, chortling at my luck.
"You do know that they don't expect more than fifty people and this room can hold one hundred?"
Good seat luck, bad gorilla luck, guess you can't win them all.
To read the rest of the blog, head over to The Gorilla Coach

Thursday, May 24, 2012

So long and thanks for all the bananas

"Keep coming, straight back, doing fine. Oh, you might want to watch out for…"  <crash> "that lamp…"

Doing my best to not tip over the moving dolly I glared at Hogarth. "A little more warning would be helpful."

Hogarth gave me a shrug. "What do you expect from an imaginary gorilla? Besides, when have you ever listened to me before a problem happened?"

I sighed, he had me there. With a shrug, I wheeled the boxes around the broken lamp.

Plenty of time to clean up the mess, we were going to be a while after all.

Breaking a branch off one off my newest fichus, Hogarth said. "No place like home."

Moving Day

On November 05, 2009 I published the first of Hogarth and my adventures in blogging. With a motto of "I've done a lot of stupid things, no reason anyone else has to." Google Blogger made getting started very easy and I've enjoyed my time here at "The gorilla is named Hogarth.

Yet all good things must come to an end. And with an end is a new beginning. Today Hogarth and I moved into our very own space. Moving forward you'll find us at "Thegorillacoach.com."

Thank you, Google and we'll see all of you on the Gorilla Preserve.

Joel and Hogarth

Friday, May 18, 2012

The Gorilla Hero- Project Management's Super Power

“Preparing shock, move away from the patient! “
What the? The sound was muffled by the partially closed door to my office. I shoved open the door of my office to see what was going on. And promptly wished I was still in the quarterly business review being grilled by the CFO.
A massive gorilla was kneeling in the center of my office. His massive torso obscured my view of what was beyond him and only made me more concerned as all I could see were a pair of human legs that I assumed were connected to a body lying on the floor.
“Shock will be delivered in 3, 2,…”
“Hogarth!” I rushed into the room, trying to see who my personal gorilla was leaning over. My mind praying it wasn’t Bob as he still owed me the initial set of product owner user stories to start release planning. In retrospect, not the most compassionate thought, but it was the heat of the moment. \
“Shock delivered, it is now safe to touch the patient.”
I cleared Hogarth to look down on his victim. Only to find the empty eyes of a CPR dummy staring up at me. A portable AED was lying next to the dummy, it's cables snaking out to the test pads stuck on the dummy's chest.  

“Hogarth!, what are you doing?” You’d think I’d get tired of asking this, given how often I find myself asking it in any given week.
Looking unnaturally large as he hovered over the mannequin Hogarth pointed at the device. "Practicing," he said matter of factly. "Don't you remember the CERT training is coming up? I want to be ready when we go."
"Hogarth, I'm not signing up for the Community Emergency Response Team." I stepped over the CPR dummy and made my way to my desk.

"Really?" Hogarth said. "I would have thought you would have jumped at the chance. You're always advocating people do more. You know responsible authority and all?" 

I sighed. "Yes, I do believe in stepping up, but that's different.  I’ve got nothing to offer for CERT. I’m just a software project manager. I don’t have any medical training, I don’t know jack about construction and if you hadn’t noticed I’m far from what you'd call a Greek god of fitness. I'm anything but fire fighter material."
Hogarth settled back on his haunches. One long arm snaked out to my bedraggled fichus and came back with a branch. "Uh huh," he mumbled through a mouthful of leaves. "Let me ask you this, when you are brought in to help on a problem project, what do you do?"

I didn't have a clue where Hogarth was going with this. I did know that this was familiar ground for me. "Easy, start by gathering data, figure out what's gone wrong, create an "state of the project", create a plan of action to correct, execute and then keep going back through the cycle in a tight iteration loop until the project is on track or done."

Hogarth nodded. "Interesting. Sounds a lot like this." He handed me a printed PowerPoint slide that bore the title "CERT Sizeup."

More than a little annoyed at this delay, to my getting real work done, I skimmed my eyes over the slide. I blinked. I read the slide more closely, taking in each of the nine steps a CERT team goes through when assessing an emergency scene. "Oh… my… That's"

Hogarth nodded, "Just like project management?"

I really hate it when he's right.

Project Management is Leadership and Leadership is needed
In many ways this blog ties back to the Responsible Authority Gorilla.  No matter our authority, we have a responsibility to the project. Combine this with the ethics taught by professional certifications like the PMP and I argue this responsibility extends to helping those around us, with the skills we have developed.

That's all well and good, but project management isn't exactly a life saving skill?

Really? Take a look at the slide Hogarth showed me. It is from the national Community Emergency Response Team training for sizing up an emergency site.

Looks familiar, doesn't it? The process a CERT member goes through, to assess and deal with an emergency situation, is a lot like what we project managers go through when dealing with a project. I've seen lighter weight process frameworks than the CERT checklist. When you start learning about the Incident Command System, a national standard framework for how multi-agency and jurisdiction response to a disaster is handled, then you really see how our training, as project leaders, can be an asset to our community.

I'm currently taking CERT from my local city. This free training is offered by many communities to create a core of citizen volunteers that can help out in the event of disasters or major emergencies. When fire and medical is overwhelmed, CERT teams are become the "First Responders" and can often make a difference between life and death. Most of my fellow class mates are taking the class as a response to the "Glenview incident", what most of the world calls the San Bruno Gas Pipeline explosion. I, on the hand, am continuing a long tradition of community service.

I first learned CPR and First Aid in college as part of the Resident Assistant program for my dorm. I eventually ended up as the ERT Captain for one of my former companies, over seeing a team for a 1500 person campus. In the course of that time I've contributed to saving at least two lives and preventing several more people from having more serious injuries had I not been a first responder while the fully trained medical people were still in transit.

I'm no hero. I believe in helping others and I've learned that the skills I use to manage troubled projects are just as effective in managing the response to a disaster or medical emergency.

Good project management can change the world. Even if it is just one band aid at a time.

Joel Bancroft-Connors

The Gorilla Talker

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

You can follow me on twitter, @JBC_PMP

Friday, May 11, 2012

A Gorilla Primer: What the heck is Agile?

"It's all rather simple." I said confidently. "It's a process to maximize our transparency so that we can deliver the maximum effectiveness of end purpose value to our constituents while ensuring the highest possible predictability in deliverable milestones ."  

Hogarth cocked his head to the side, "I'm not following. I thought this was supposed to be easy?" 

I tossed my hands in the air energetically. "It is! That's the beauty of it. Why the framework for one implementation can be summed up in ten minutes." 

"Really, so what's the value?" Hogarth asked. 

"Total optimization!" I beamed. "Using a collaborative team structure you generate value in an iterative cycle that completely optimizes your process and maximizes customer return."  

Hogarth looked at me for a long moment. Finally he reached up to scratch his chin. "Huh… I'm still not sure I'm following. How is this different from waterfall?"  

I jumped up "Totally different! It will change the world!" 

Hogarth shrugged, "How?" 

I let out an exasperated sigh, "Have you been listening to anything I've said? Haven't you read anything about this?"  

He nodded, "Yep and I'm still not understanding what's in it for me." He opened up his arms, "If you're going to sell me on a new way of doing things, you have to tell me what's in it for me and you need to use small words." 

"What's in it for you? Why that's…." 

Well damn, the gorilla was right again. 

What the Heck is Agile?
A blindingly simple question that is a lot harder to answer than one might think. Trust me readers, I will get to the answer, just bear with me a moment as I expound.

I'm an experienced agilist, I speak about agile often, and I write about agile regularly. And the other day I found myself trying to explain agile to a program manager who had zero knowledge of it.

Wow… It's not that easy.

First problem, where to start? I took part in the May 11th #PMChat twitter chat, which had a topic of "An Intro to Agile." It was a great Tweetchat, with a lot of valuable information. Only it would have been better called "An Intro to Scrum." That's great, it was a good topic and judging by feedback, very informative.  Only Scrum isn't all that is agile. When discussing agile, do you start at the nuts and bolts, or do you start at the overarching philosophy?  

Or maybe… You start with the user.  

User Stories: Skipping ahead to an advanced lessons, we find that User Stories are different from requirements in that they are focused on the benefit given to the user. So maybe we should be using the same concept to explain agile. Today is version 0.1 (zero dot one [zed dot one for British folks]) of my agile primer.  

Let's look at our users and what agile can do for them: 

Company President- Do you want predictability? Do you want happy customers? Do you want happy shareholders?

Agile is a company initiative that creates more predictability in releases and allows the company to quickly adapt to the customer's needs. Through happy customers your company has happy shareholders.  

Product Manager- Do you want to be able to change your mind? Did your customer change their mind? Do you want what really matters, when you need it?

Agile is a flexible product design process that allows you to adjust the product to meet changing customer priorities. What ships is what the customer really needs (and will buy).  

Manager- Do you  really want to be looking over your team's shoulder every day? Do you want to help your people grow, not just make the next code drop?

Agile gives your team the ability to what they do best, create. It gives you the ability to do what you are best at, helping your team grow.  

Project Manager- Are you tired of chasing down everyone with the age old "What's your status?"  Are you tired of living in the DMZ between product management and engineering? 

Agile is founded on transparent communication and puts deep focus on collaborative solutions that have the whole team working towards a common goal.  

Developer- Would you like development model that puts the power in your hands? Do you want to decide how to build something? Do you want management to listen to you when you say it will really take three weeks?

Agile lets you be directly involved in helping to define how something will get built and even what gets built. The company puts its trust in you to make decisions and listens to you when you say how long something will take. Schedules are based on what can be built not some artificial line in the sand.

Great, so what exactly is Agile?
Ah yes, once we get past the benefit we still have to figure out just what agile is.  

An early attempt I had at a one line summary is: "a customer focused, iterative process that is executed through a collaborative effort of the team and company."

Yeah, I know, with that kind of double speak I should be in politics.

Agile is:
  • Listening to the customer throughout the entire development process, not just at the beginning.
  • Focusing on the team. A better team makes a better product. Trust in the team.
  • Building with GPS. You're constantly making sure you're on course.
  • Learning from mistakes, not just writing them down at the end of the project.
-  and -
  • Not new. The term is new, the ideas reach back decades. We owe the Agile Signatories for helping bundle the concepts into a single word.
  • Not a methodology. It's a set of principles and values. Below these are frameworks like Lean, Kanban, Scrum and XP.  

At its barest essence, that is what agile is. It's not some secret, make it all perfect, sauce. It's hard work and incredibly rewarding. It's moving from shareholder value to customer value. Go read the Agile Manifesto. It's not about process, it's about results.

Okay, and?...
Right, that and four dollars will buy you a cup of coffee. What do we do with this? Good question. Agile itself isn't a solution. Agile is a mindset, a way of thinking, of interacting. You still need a framework to work within. The are four common agile frameworks, Scrum, Kanban, XP and Lean.

In a nutshell:
Scrum- Is characterized by its iteration cycle. At the start of a sprint (1-4 weeks), the team commits to working on a certain amount of the Product Backlog (Everything we want built). They meet each day to review progress and impediments. At the end of the sprint (iteration) they demonstrate working results (no PowerPoint). Then the team reflects on how the team did and what can be done to get better.

Scrum can be very good for new development, where uncertainty is high, change is constant and the customer is involved.

Kanban- Kanban has evolved from Just in Time manufacturing concepts. Its primary characterization is the WIP, or Work in Progress, that limits what can be pulled from the Queue (What needs to be done). It does not work in iterations, instead working in available workload. By limiting work in progress, you limit waste and generate greater focus by reducing multi-tasking. It's other driving factor is it starts with where you are now, and works to get you to a better process. Where most frameworks are replacements for existing methodology, Kanban focuses on continuous, incremental improvement from where you started.

Kanban can be very good in maintenance, where each item is often unique.

XP- Extreme Programing is probably best known for the concept of pair programming. XP is known for pushing the limits of traditional practices (hence "Extreme"). It also uses short iteration cycles, typically, one week max, as well as demos and retrospectives. It is also heavily leverages code reviews, unit testing and automation. Typically more so than Scrum. The average person will see little external difference between  XP and Scrum.

XP is very common with start ups and for projects that extremely dynamic or have few starting requirements. You are rapidly prototyping to a final product.

Lean- This practice is best characterized by the elimination of waste. Anything that does not create value for the end customer is considered wasteful and a target for elimination. It's a "do more with less" framework that at works primarily thanks to strong principles that oversee the structure. Toyota's Total Production System is the most common example of Lean.

Note: Some will argue that Lean isn't agile. Not being an adherent to any one framework I see Lean as sharing many of the same principles and thus put it under the loose umbrella of agile. It's easier than calling them all "customer focused, iterative development practices that focus on the team."

Lean is most common in manufacturing, where the product is relatively fixed and the improvements are focused on how to produce the product better.

Anything else?
Oh, Gorilla, yes. There are stacks of books and gigabytes of blogs on agile. I can't even begin to scratch the surface with all my blogs. Let me leave you with some additional resources and one last thought.  

Elements of Scrum- Great primer book on the Scrum methodology. I reviewed it last year. The authors also just released a 50 page super primer. Only $0.99 on Kindle.
Mountain Goat Software- Mike Cohn is one of the leading educators of agile. His web site is full of information.
Agile Leadership Network- Find a local chapter. Meet people who also believe in changing the world.
Wikipedia- Seriously, the articles on Agile are very extensive and a great way to get started.

One last thought: All the above is a fairly basic and fact based review. I'll want to leave you with why I use agile. We've spent several decades with companies focused on shareholder value. I think the time is coming to swing back to focusing on customer value. We've also spent the last several decades focused on getting more out of our teams. I think it is time to start giving more to our teams.

I think agile is the key to these changes. I think the values and principles of agile and lean will change the world for the better.

And I want to help.

Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP  

Thursday, May 3, 2012

The Abilene Gorilla: Going with the flow isn't always

I flung my door open only just catching it before it slammed into the wall and left a hole I wouldn't want to explain later. Resisting the urge to throw my notebook across the room I stomped towards my desk, registering the presence of Hogarth decimating my newest fichus tree.

For once I was almost happy to see Hogarth. Almost happy. At least I had someone I could complain to. "We are so doomed," I said as I tossed myself into my chair. It gave a whimpered protest, at the abuse,  though held together in the end.

Hogarth raised one eyebrow, which for a being with a monobrow that was no small achievement. "The Mayan's were right?"

I leaned back in my chair, throwing an arm over my eyes to blot out the light. "We should be so lucky. At least if the world ended I wouldn't have to watch our profits tank faster than skydiver who forgot his parachute." The deafening silence that greeted my answer  eventually caused me to peak out from under my arm and make sure Hogarth was still there. He was, just staring at me with those impassive brown eyes.

Sigh, here we go again. "The president just decided we should do a radical pivot of our business model. It's absolutely insane and it's going to kill our business. All you have to do is look at the recent customer feedback to know it was a bad idea."

Hogarth carefully set the denuded fichus branch down before speaking. "Well did he?"

"Did he what?"

"Did he look at the customer feedback?" Hogarth asked.

I tossed my hands up in the air, "I don't know. I didn't ask."

Hogarth cocked his head to the side, "Why not? Wasn't this a strategic brainstorming meeting? You all meet to throw out ideas and see what sticks."

I shook my head, "Hogarth, Hogarth, you don't understand. The president asked 'What about doing X?' No one is going to argue with his idea, he's the president." Pointing at my chest I said , "It's not my job to rock the boat ." 

"Isn't it?"

"Stop playing twenty questions with me!" I snapped. "He's the boss, we do what he says. He knows what he's doing."

"That doesn't mean he thinks it’s a good idea. He's the president, he has to look like he knows what he's doing."

I glared at Hogarth, "What's the difference?"

Hogarth looked at me. "Ever been to Abilene?"


"The Abilene paradox is a paradox in which a group of people collectively decide on a course of action that is counter to the preferences of any of the individuals in the group. It involves a common breakdown of group communication in which each member mistakenly believes that their own preferences are counter to the group's and, therefore, does not raise objections. A common phrase relating to the Abilene paradox is a desire to not "rock the boat"." - Wikipedia

The paradox reminds me of the lemming poster I used in "All the other Gorillas are Doing it" blog. The Abilene paradox is a solid reminder that no matter where the idea comes from, as a people or project manager, we can't blindly assume that it is a "good" idea. If you have concerns it is your duty and responsibility  to raise those concerns. You can't assume someone else will. Even in the most CEO dominated companies (can you say Apple?) it takes a team to design and build an idea.

But the nail that sticks out gets hammered down

Ah yes, the old Japanese proverb that espouses conformity and not making waves. Sure, no one wants to be the little kid who yells out that the Emperor has no clothes. Only ask yourself this, do you really want to be the Emperor's servant when he finds out he's been parading around in public without any clothes on? The problem with this approach, is what if there really is a squeaky wheel? If everyone chooses to ignore the squeak it doesn't go away. Eventually the wheel seizes up and flies off. Then where are you?

Let's instead look at another Japanese proverb, this one from Toyota. 

"Stop production so that production never has to stop."   or, as the Toyota Production System sums is up,


This is what empowers every worker on a Toyota production line to be able to stop production if they see a problem. Not only do they have the ability, they are empowered and encouraged to use that ability. Every step of the way, assumptions are challenged and reality is tested. While Toyota has had some recent setbacks in quality, no one can deny their decades of stellar quality nor is their little doubt they will be returning to those quality roots. It is what has made them the brand and success they are and Jidoka is no small part of that.

So the next time something seems so obvious that everyone knows it, open your mouth and make sure everyone does know. Don't end up going to Abilene when the restaurant down the street is what everyone really wanted.

Joel Bancroft-Connors
The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP