Category Archives: Teamwork

How is a Gorilla Project Manager like R2-D2?

Posted on by
4

“So what do you do?” 

See, this is why I hate dinner parties. Now if I was a doctor, a pilot, heck even a mechanic, it would be easy. I’d just say it and we’d move on to the meaningless small talk portion of the evening. But no… I had to decide to become a project manager, even worse an agile project manager. With a deep internal sigh I sized up the person who had just asked me the question. 

Neil was nice enough, but I could already tell it was going to be an uphill battle. He was the neighbor of the host who was a friend of my wife’s. I already knew Neil was in Real Estate (he’d left a stack of his business cards in the bathroom), I didn’t relish the next few moments.  

“I’m a project manager.”  

Neil cocked his head to the side. The look of confusion on his face was all too familiar. Taking a breath I tried to explain. I don’t know why I did. It’s not like I’d ever had any success before. And yes, I’ve tried the “I heard cats for a living.” I really didn’t want to be asked what circus I worked for again.  

“I’m responsible for managing the scoping, planning and execution of project deliverables with a cross functional team in order to get a product shipping.”  

“Oh, so you’re a manager?” Neil asked. Of course what he was really asking was if I was in charge of people. Why is it that a measure of your worth is how many people call you boss?  

I shake my head, “No, I don’t have direct reports. My job is to facilitate the project and help the core team deliver.”  

“Like a hostage negotiator?”  

I sighed. Smiling, I nodded my head. “Yeah, just like that.”  

“Cool.”  

I wasn’t even going to try and explain how agile project managers were more like coaches. Not being a sports fan myself I didn’t want the conversation to go down the rat hole of how I thought the local pro sports teams would do this season. 

Just then I spotted a dark shape duck around the side of the house. Hiding a groan I excused myself from Neil and left the smell of BBQ cooking on the patio behind me. Coming around the corner of the building I found what I feared most.  

“Hogarth, let go of that branch.”  

Hogarth turned towards me still holding onto a large branch sticking out from the tree in the side yard.. “This is an Arkansas Black apple tree, do you know how rare those are?”  

“Hogarth, you can’t eat that tree, it’s not yours.”  

He gave a sigh and let go of the tree. “Fine…” He flopped to the ground and picked at the overgrown lawn. “You won’t begrudge me a little grass, will you? I’ll give you the secret of explaining your job.”  

“Hogarth, I’ve been a project manager for years. There are even people in my company that don’t have a clue what a PM is.”  

Nibbling some of the green grass he looked up at me a smiled a toothy white grin. “That’s ‘cause you never told anyone that you’re R2-D2.”  

“Wha…?”

  

R2-D2 – Robot side kick to the Skywalker’s of Star Wars and Agile Project Manager: He’s not the hero of the show and he’s never been a leader, but it would be hard to imagine the Star Wars universe without this plucky little trashcan on wheels. But what does R2 have to do with being project manager? 

Everything! R2 is the ultimate Agile Project Manager. Or perhaps we project managers are the ultimate R2 Astromech droids.

R2-D2 knew all about responsibility without authority: Princess Leia, his project sponsor, assigned him the project but gave him no resources to do it with. He even had to track down the product owner for more information. He enlisted C3PO on the force of their relationship alone. As the project progressed he collected more resources on influence or by working with his project team.  

R2-D2 understood that project requirements change: When his sponsor first gave him the project it was very simple, get this message to Obi Wan Kenobi (his product owner) so that Kenobi could stop the Death Star. But he knew the requirements would change. He didn’t demand a full list of requirements before he headed for the escape pod. He was confident that future backlog grooming would reveal more requirements. He also knew that iteration planning would break the epic scale user stories down into smaller stories and tasks. So he started the first sprint with just a couple of user stories. Engage existing resources. Get off the Ship. Don’t get shot.  

R2-D2 knew how to motivate his teams: When R2 met Luke Skywalker, he knew who the boy was. He leveraged past project retrospectives for that (Okay, he was in the first three movies). So with that in mind do we really think he accidentally showed Luke the holo of the princess? Heck no! He remembered that Obi Wan told Senator Bail Organa he would watch over the boy. So by revealing the holo, not only would he possibly find a clue to where his product owner (Kenobi) was, but also could motivate the young man to help the project.  

R2-D2 knew his job was to guide the use of proper process, but also knew that sometimes you trust your team: Process said you used a targeting computer when firing a proton torpedo. But he chose to trust his team member, Luke, when he turned off the computer. Good thing he didn’t stick to rigid process enforcement, right?  

R2-D2 knew all about removing impediments: Shut down the trash compactor. Fix the hyper-drive. Stop the elevator from falling. Shift power to the rear deflector shields. Open this door. Put C3PO’s head back on. Put C3PO’s head back on, again. When his project team encountered an impediment he jumped right in and owned clearing that impediment.  

R2-D2 was the ultimate servant leader: R2 knew exactly what needed to happen. After all, he’d been working on related projects since the Phantom Menace. By the time it came time to destroy the Death Star, good old R2 knew all the players. He could have told Luke that Vader was his dad on the first day they met. But he didn’t. He knew he had to let his team member discover some things himself. Instead he carefully guided his team member on the path. 

He was never the hero, but he always saved the day. He worked quietly and tirelessly in the background to ensure all went well. Emperor Palpatine may not have known who he was, but his team did and they appreciated him for his efforts. 

So you see, the next time someone asks you what you do for a living. Stand up proud and declare. 

“I’m R2-D2.”

 

Gorillas can be Agile with any project

Posted on by
1

Some days I was so thankful for the fact I worked in a three story building. It made the urge to toss myself off it, to end the misery, so much less. Unless If I  was really lucky I’d just end up hurting myself and that would just add to the miserable condition I was in.
Hogarth was right… Oh how I hated to think those three words. It was becoming such a common occurrence that I was considering adding to the law’s of nature. The sun comes up in the east, politicians are lying when their lips are moving and Hogarth is always right. This time it had to do with my implementation of Agile. Agile may be the silver bullet of development but I hadn’t had the first idea how to properly implement it.
So I’d swallowed the pill and went out and figured out just what Agile was. Leaning back in my chair I took in the remains of that discovery. Highsmith was leaning on Adkins and the two were threatening to push Cockburn off the desk. Larsen and Cohn were glaring at me from under the coffee cup perched on them. The books stared back at me mutely, mocking my pain and despair. Tilting my head back to stare at the ceiling I moaned. “Kill me now…”
“What and miss all the fun?”
I kept my eyes closed and used every ounce of my will to imagine away the voice that had spoken.
“Not gonna work,” Hogarth replied. “Your subconscious really likes me, so you’re stuck with me.”
Pulling my gaze from the acoustical tile I fixed Hogarth with a baleful gaze. “Remind me to schedule myself for a lobotomy.”
Hogarth was perched on the large window ledge. His black fur shimmering in the afternoon sunlight and his face was split with a contended grin. “Now why on earth would you want to give up all this?” His huge paw swept in an all encompassing arc that took in my cube and then the rest of the office beyond.
“Because there is no way on earth I’m going to get the company to adopt Scrum for real!” I poked at the stack of books. “It’s a far cry between some structural artifacts and the real meaning of Agile and the company is about as unagile as you can get.”
Hogarth nodded, “Well yeah, I think we covered the whole artifacts part already” He snaked an arm out the open window and broke off a branch from the tree outside. Snacking on the branch he said, “You’ve recognized the real problem so what’s the issue?”
“There is no way on earth I’ll ever get this company to go agile.”
“Agile or Scrum?” Hogarth asked.
“What’s the difference?” I shot back.
“A single sapling a forest does not make…”
Scrum is an Agile Framework – Scrum is not the only way to practice Agile.
When these kind of comments are thrown out, the typical response is something like “Well of course, there’s Kanban, Lean, or XP.”  And those folks are right, these are other frameworks or methodologies  of Agile. And at the same time I think we end up missing the bigger picture. To understand this, we need to look into the roots of Agile.
Agile has two foundational roots. The most obvious is the gathering of software luminaries that created the Agile Manifesto. Agile wasn’t some earth shaking new concept. What it was, was the joint thinking of seventeen software developers who had been practicing various lightweight development methods and how what was the common, foundational values of these methods.  At its heart Agile was a new language to explain long standing best practices, values and principles. If you think about it, in a light weight Agile way, it is the Agile PMBoK. (Remember that the PMBoK is also not a methodology, but a set of standard terminology and guidelines for project management.)
The other foundational root goes back to the precursors of Lean manufacturing, to the Toyota Way. Like the Agile Manifesto, it was not until 2001 that Toyota published the “Way.” But in Toyota’s case it was not for lack of use. Toyota revolutionized automotive manufacturing with their unique style and for decades US companies tried to match it. It’s not as if Toyota was a walled garden. They cheerfully gave tours of their plants to any and all comers. Why? Because they knew the artifacts of their process were not the key. The key was their six underlying principles, such as “Respect for People,” and “Add value to your organization by developing your people and partners.”
So what’s your point?
Ah yes, this is not a history lesson and I am trying  to make a point.
Today I read a great blog that sums up my point nicely. Ben Horowitz wrote about Lead Bullets, on TechCrunch. The kernel of this is to not go looking for the silver bullet solution, instead use the bullets you have and shoot better.
I’ve heard stunning success stories in the use of Agile Methodologies (Scrum, XP, Lean, etc.) In nearly all of these instances, the support and engagement was across the board high. It was the right time, the right people, the right need and so on. The Perfect Project Storm. In these cases the silver bullet was the only bullet and it was a dead shot.
And I’ve seen people try and use the Agile silver bullet and have the organization smother them alive. I like to remind people that silver bullets only work against werewolves. If you are facing a ghost, you’re kind of out of luck. When faced with an organization that is highly resistant, highly process driven, highly dysfunctional, etc. trying to dive into the deep end of the Agile pool tends to only end up in the Agile project and team being drowned.
I’m even more depressed now, wasn’t there a point?
Yes! The point is Agile isn’t just an umbrella over methodologies,  like Scrum and Lean. Agile is a set of guiding principles that can be used ANYWHERE. Where is it wrong to have good teamwork? When is it wrong to make sure the customer is getting what they want? If the process plan says to roll the parts cart around the outside of the building twice, before entering, is it wrong to ask “Why?”
Enter the Agile Manager. You don’t have to be using Scrum to be Agile. You can use the principles of Agile anywhere . You can make any team better, if you try.
In short, don’t let bad methodology get in the way of good management.
Focus on the team and the project will improve. That’s Agile.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

No one expects the Gorilla Retrospective

Posted on by
2
Jake was pinned to his seat by the spotlight’s intense beam. “Where were you when the code check-in introduced four P1 bugs?”

“I, uh, what?” Jake stammered.
I spun the spotlight and speared Bob with its white light. “The requirements document failed to take into account the Fergusson account. Why?”
Bob shifted in his seat. “It was Jane’s fault, she didn’t file a sales report for Fergusson!”
Jane’s mouth dropped open and she reached for her cellphone. Somehow I didn’t think she planned to text Bob with it. Not from the way she was holding it over her head.
Now I was getting somewhere. This post-mortem was finally getting to the bottom of things.
But before I could turn the spotlight towards Jane, a figure leaped onto the table and blocked my view. Jumping back, I looked up at the strange visage before me. Yards of red satin swirled about, all but obscuring the figure beneath it. A red galero covered the figure’s head, its deep crimson so dark it nearly blended with the black hair that lay beneath it. The darkness of satin and hair offset the brilliant white teeth of my interloper, making him suddenly recognizable.
Hogarth struck a preposterous pose and declared, “No one expects the Gorilla Retrospective!”

The Post-Mortem:
If you have ever sat through a grueling multi-hour project post-mortem, you probably wished for the inquisition to sweep in and put you out of your misery. The very term means “after death.” What a delightfully pleasant term for this meeting. Let us examine the corpse of the project and see what killed it. Let’s not trouble ourselves with the fact that the project actually shipped and is a success. No, that would be pointless.
The purpose of the meeting is to tear apart the project and find everything that went wrong. As the project manager, you will assemble a mammoth document that goes into sickening detail. Even if you tell people “we aren’t here to blame anyone”, blame will be assigned and buses will be thrown on top of people (or something like that).
And when it’s all over, the report is dutifully filed in some file cabinet (real or virtual) and promptly forgotten. No one goes back and reviews it. No one wants to remember the painful experience of exhuming a successful project for failures.
A rose by any other name:
Okay so we won’t call it a post mortem. How about lessons learned or a retrospective? Yeah, that’s the ticket. Now who’s fault was it that we shipped with no user documentation?
You can slap lipstick on the pig and it will still be a pig. Changing the name of something, but not how you go about doing it, is just going to make folks dislike the new name as much as the old.
So many companies look back on their projects to find what went wrong and fail to try and do better the next time.
Break off that rear view mirror:
I’ve met no small amount of people who think the George Santanya quote “Those who cannot remember the past are condemned to repeat it” means we have to live in that history. Relive every mistake and wrong to determine exactly why it happened.
Not so. The horses are already out of the barn. Grilling the ranch hand on why he left the door open isn’t going to do much. It doesn’t get the horses back and it doesn’t really do anything about the future. Manager Tools recently did a podcast called “There is no why in feedback.” The Feedback Model is a manager tool for communicating about both the good and not so good things your directs do. The big key to it is that it doesn’t focus at all on the past behavior. It just focus on the future.
 An example:
“Don, can I give you some feedback? <wait for answer> “When you are late to the meeting, we start late and can’t finish the agenda. This means not everyone gets a chance to be heard. Do you think you could change that next time?“
Read the last sentence again. “Next time.” The manager doesn’t dwell on the previous issue, instead he dwells on it not happening again.
And that’s the secret to a great retrospective. Focus on the future. Don’t assign blame. Don’t dissect every problem. Don’t get lost in the spilt milk. Focus on doing better the next time.
Forward looking:
When I do a retrospective I pull out another tool from my Manager Tools bag. On the left side of the white board I write “What Went Well.” On the right side I write “Things to Look At.”
The latter is important and I always stress it. TLA isn’t about blame, it isn’t about why, it isn’t even about negative. It is simply things we want to look at for the future. This can mean you end up with things people would generally refer to a “positive” on the Things to Look At side. After a good retrospective, I often have lines drawn from items on the WWW side to the TLA side. Things that were not part of the normal process, that had a good impact and the team wants to do it again.
The next step is to lay down the brain storming rules. When using the brain storming rules there is no “No”, “But”, or “I don’t agree.” Brain storming is a safe zone where anyone can throw out anything and there will be no discussion, no argument and anything goes. If someone yells out “Pepperoni Pizza,” my only response is “Is that a ‘Went Well’ or a ‘Things to Look At’?”
When you’re done collecting your WWW-TLA you then give everyone something to vote with. Small teams can use markers, larger teams work well with stickers or even post its. Let everyone vote two or three times on the TLA side. Then you tally up the votes and you’ve got your top things to look at changing for the next time. Short, sweet, to the point and very effective.
Don’t make your retrospectives a full court trial. Don’t dwell on the past. Do make it safe for people to reflect. Do focus on the future.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Wake up and smell the gorilla

Posted on by
3

Or: Finding my own business philosophy and what matters

The training room was packed. Nearly everyone from the department was there and we were all interested to know what the all hands meeting was about. Things were going really good. The company was doing great. We’d gotten past the uber release of the year and were all breathing a sigh of relief. My job might not have been exciting or “filled with growth opportunity” but it was nice and safe.

Then boss of all the bosses in the room stepped up to speak and we all settled into quiet. Our eyes open and ears listening.

I know he said other things, but somehow everything he said was lost in an unrelenting roar of six words as they repeated in my head, over and over again. “Your services are no longer required.”

My jaw dropped. That’s okay though, the floor had fallen out from under me and my jaw was just trying to keep up with the rest of my body. What happened? This was a safe job! How did I miss the writing on the wall, I mean there’s always writing on the wall. Isn’t there?

“Of course there is.” I turned to look for the source of the voice. I didn’t recognize it, but the voice was somehow familiar. It was almost like I should know and was just having amnesia.

“Selective amnesia, sure I’ll give you that.” The voice was attached to two rather large, extremely hairy feet. Said feet were propped up on the table next to me. Following the feet back up the equally hairy legs I was eventually greeted by the visage of an 800 pound gorilla.

“What the hell are you?” Not exactly the most sane response to meeting a talking gorilla but I can’t imagine Elwood P. Dowd handled meeting Harvey much better.

“I’m your fairy career gorilla.” He grinned, showing a mouthful of blindingly white teeth. “Well technically I’m your ‘So blindingly obvious you can’t avoid it’ combined with ‘That problem you know is there but would rather ignore, gorilla.’ Course you could just call me Hogarth, that’s my name.”

“I must be hallucinating. Or maybe this is just a bad dream. I’ve been under a lot of stress lately, this is just stress giving me bad dreams. Yeah, that’s the ticke…”

Smack!

I think I’ve mentioned before how unnerving it is to be smacked by a figment of your imagination. The first time was no less so. And it’s damn  hard to ignore a figment of your imagination that makes you see double. Blinking, I looked at the fuzzy image of two gorillas. “How long have you been sitting there?”

Hogarth folded his ample hands over his chest and spoke serenely, “I have always been here, you just were not prepared to see me.”

“How the hell can you miss a 800 pound gorilla in the room?” I asked in complete disbelief.

Hogarth’s reply was to wave about the room. All about me were faces in shock, disbelief and sadness. HR Minions, the dislike of their current job evident on their faces, moved about the recently dispossessed like clerics ministering to their flock. But no one paid any attention to Hogarth. “People see what they want to see, they understand what they want to understand.To truly understand the source of a problem, one must be prepared to look for it in ever increasing circles about oneself”*

*This quote is paraphrased from Mark Horstman

 

MY AHA MOMENT- I’D BEEN CAREER COASTING 

And so was my “aha moment”, my “game changer”, my “Waterloo”. Or in normal speak, it was getting laid off from this “safe” job that finally made me stick my head up over the cube wall and look around.  

In the days right after the event I went through the normal five cycles of grief, denial, anger, bargaining, depression and finally acceptance. It was with acceptance that I found out something fundamental. Something that changed how I looked at everything. With acceptance I gained the realization that getting laid off was the best thing that could have happened to my career. I felt like that guy in the romance comedy movie. You know, the one who’s in love with the super perfect, if not a little boring, woman and is devastated when she leaves him, only to realize his best friend has been the girl of his dreams all along? Being shaken from the safety of my job made me realize how much I was to blame for where I was. 

For some of us, it takes a two by four to the head to see the blindingly obvious. My two by four was being laid off and what I ended up seeing was Hogarth. Okay, I didn’t really see a 800 pound gorilla, but what I did see were things that had been right in front of my face all along and I was too focused, blind or in denial to notice. 

And so I began to make the changes to take control of my career. At first it was the absorption of knowledge I’d ignored for so long. Reading books I’d long owned, long had looking impressive on my office shelf and had never read. Checking in with the real world and what was going on. And discovering new voices that spoke words of common sense, words I’d been deaf to before. 

And then I began to realize I had everything I needed to take charge of my career. I learned enough to see that I already knew how to be more than what I was. I started to understand I already had a set of principles, a personal business philosophy. I just needed to start following my own inner gorilla. 

Over the last two years I’ve put to writing my own guiding business philosophy. Covey might call it a mission statement, Agile calls them values and Manager Tools just calls it being Effective. They are still a work in progress, but they color my daily work and the blogs I write here.  

The one caveat I should give is that this isn’t anything new or profound. This isn’t rocket science, or as the fine gentlemen at Manager Tools like to say “Management is boring, but it is effective.” I’m not the guru of a new world order, I’ve just put some common sense into a coherent form and am doing my best to follow my own guidance. 

The Gorilla Philosophy:

1- People, not projects

2- Communication is 100% your job

3- Process is a tool, not a roadblock

4- There  is no, one, right way

4- Everything leads back to the Customer (Stakeholder, End User, etc.)

 

Stick your head up and look around, is there a gorilla waiting to talk to you?