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

Coachin Agile Teams

Note: For new Gorilla Blogs, head over to The Gorilla Coach
 

"You've got to do something! We can't keep going like this, the entire project is going to collapse in on itself."

Eric certainly had a way of getting my attention. I had instant visions of red project dashboards and burn down charts flat lining like a patient in the ER. Eric was one of the canaries on the project. There are always those certain team members that reflect the state of the project or are the first to see a major issue. Like the miner's canary of old, they are the first to notice or raise the issues and a smart manager learns to pay attention. These are not to be mistaken for the Chicken Littles, who can give a hypochondriac a run for their money. When a canary sings, you listen to their song.

I held up my hands and spoke in a calm tone. "Okay, Eric, calm down and tell me what the problem is. I'm sure we can get this addressed."

Eric took a deep breath and paused for a moment, as if suddenly unsure he wanted to continue. I gave him my best supporting smile and waited.  Finally finding his voice he said, "It's Greg, he smells."

I blinked. "Smells?"

Eric nodded, perhaps a bit too energetically. "No one wants to pair program with him. Heck no one wants to be within six feet of him. It's like a mouse crawled into his shirt and died. Given the last time he changed his shirt it could well have."

I sat back in my chair, a frown threatening to crease my brow. "This can't be happening to me," I thought. My next thought was to look across the table again. If Brenda were sitting there, this would have been another "The sky is falling" moments and I could have dealt with that like all the other times the sky didn't really fall. Only this was Eric, the most reliable barometer of the teams health available. It meant that either Eric had gone off the deep end or the problem was very real.

So now what? This wasn't a slipped schedule, we didn't have a shortage of test machines,  it wasn't even the completely useless requirements or product manager owner was foisting on us. No, I was being asked to deal with someone's smell."

They didn't cover this in project management training…

"What would coach do?"

I turned to cast a baleful look at Hogarth.

"This isn't a football game."

My gorilla gave a little nod. "Good thing too, cause you stink at football."

"Hogarth you are not helping me solve this problem."

He nodded again, a brilliant white smile splitting his face. "Nope, I'm not and you shouldn't be either. Solving Eric's problem isn't going to help him solve it in the future, now is it?"

Dang… he was right.

BOOK REVIEW: COACHING AGILE TEAMS, By Lyssa Adkins

Summary:

This book had been recommended to me many times, by many people. It forms one of the core study books for PMI's new agile certification and you'd be hard pressed to find a conversation on agile coaching that doesn't reference this book or the author.

Like me, Lyssa Adkins is a recovering command and control project manager and this is one of the things that makes this book resonate for me. While many agile authors have always been on the revolutionary/evolutionary end of the innovation scale, Lyssa had worked in the trenches of traditional projects and speaks to all audiences. Whether you are an eccentric software coder, turned agile visionary, or a former art major, turned project manager, turned aspiring agile coach, this book will speak to you. Very importantly, it speaks right to project managers "in transition." Based on the traditional roles that project managers have filled, the scrum master role often ends up being a place project managers end up gravitating to as they journey into agile (or are shoved feet first by events, company, etc.) so this book is a great asset to them.

With 302 practical pages of content, there is a lot to absorb. It is not an evening's light reading. Some of the concepts and mental challenges they raised had me setting the book down so I could process. All in all, it took me several weeks to read the book as there was so much to absorb and my mind wasn't ready for it all at once.  But there was no way I was not going to finish this book.

The book is broadly laid out into three sections and the first hint you have on what it takes to be a good coach is that two of the three sections have to do with you.

• It Starts With You: Starting with the obvious "will I be a good coach?" question, this section lays down the ground work to open yourself up to what is needed for you to be a good coach. Along the way it teaches you a lot about yourself.

• Helping the Team Get More for Themselves: This section covers six aspects of being an agile coach, from the high level mentor concepts to the details of how a coach can help resolve conflict in a team.
• Getting More for Yourself: One of the things I truly appreciate about agile, is its stance on failure. Lyssa's book is no different and this section tackles head on the mistakes you will make and that it is okay to make them as long as you learn from them. It touches on the journey and knowing when you finally get there (Hint- you never do).

The Good:

Approachable Style: Lyssa writes this book in a conversational tone and weaves in direct experience throughout the book. You constantly have a strong sense that she is speaking from her own hands-on experience and her light style makes absorbing the deep content a lot easier.

Failure is okay: She knows that the journey to being a coach is going to have its bumps and bruises and she makes that okay. Instead of feeling like you are facing an insurmountable journey to be an agile coach, she reassures you that the potholes are just part of the journey. The most wonderful experiences are not found in the well manicured aisles of a department store, they are found out in the wilds of the world.

Lots of practical tips: The book isn't just theory and platitudes. She provides solid tips, actions and exercises. She also provides tailoring to help you deal with all aspects of an agile organization, not just the agile development team.

The Not So:

No punches pulled: This could arguably be in the good things, you just need to be aware about it. Lyssa doesn't pull punches and she's not going to white wash this. If you are not ready to let go of your control freak nature, this book will be hard to read. You'll put it down more than once and walk away. You will also learn really fast if you really want to be an agile coach. It is not a job for everyone. I still want to be one, but this book certainly tested my mettle.

Broad base may not appeal: If you are a hardcore scrum master, who is totally focused in on the artifacts of scrum and only scrum, you may find this book to broad for your tastes. Lyssa comes off fairly agile agnostic. This book is about helping any team, in an agile way, and this may not be pure scrum enough for some. Again, this could be argued as a good thing. I would hazard a guess that is part of why it ended up on the PMI reading list.

The Bookshelf Index: (Where does this book when I am done reading it?)

In my computer bag: This book speaks so much to what I want to be and how I want to engage with teams that it has not left my computer bag since I started reading it. It has quickly become a well worn copy and I will continue to refer to it regularly for some time to come.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

How to be a Gorilla Manager: In five easy steps

 

Dear Hogarth,

I want to become project manager. Can you give me some advice on what to do?

Thanks,

- Aspiring cat herder

Dear Aspiring,

Run, run as far as you can.

Barring that, I recommend you have your head examined. I mean, seriously, if you do your job well no one will notice you. If the project fails, you'll be standing right next to the product manager when they roll out the firing squad. Why would you want to put yourself through that?...

"Hogarth!"

My gorilla looked up from the keyboard, banana sized finger poised over the Return key. "What? Oh right, let me guess." He sat back in my chair. Amid the creaking protests of my chair he did a disturbingly accurate imitation of me. "Hogarth! What on earth are you doing?" He grinned at me, "that about cover it?"

I pinched the bridge of my nose. The pounding ache behind my eyes was threatening to burst out like some bad horror flick monster. "Yes, that covers it."

Hogarth said, "good, then we have that covered. That was easy."

"Hogarth…" I said menacingly.

He held up his hands. "Oh, right, what am I doing? I was just checking my email. Someone wanted some advice on becoming a project manager."

I blinked, "you have email?"

"Well duh. It's the 21st century, of course I have email." He shook his head like I'd asked the craziest question ever.  Okay, maybe I did. Did I?

Shaking my head I tried a different tack. "You were giving advice on becoming a project manager?"

He nodded, "Yep, don't."

"Don't?" I asked. "You do realize what I do for a living?"

Hogarth nodded, "Yep and that's why I'm advising him not to.  You're losing your hair, you've got an ulcer, and heaven knows that no one appreciates your work. Why on earth would anyone want to be a project manager?"

"Because I like helping people!"

Hogarth pointed a paw at the screen, "Okay, help him…"

And once again I had been Hogarthed.

Advice for the aspiring Project Manager (Scrum Master or Coach)

What advice would I give to a young project manager? While the urge to advise him or her to "run, run very fast," is fairly strong, it is also entirely unhelpful. And I really do like to help people, something I think makes me a good project manager, scrum master, coach, leader, etc.

So if I were to be giving advice to Josh Nankivel's students, what would I say? There are so many pithy, trite, over used things I could say. I could call on the masters of PM and just quote them. I could call on the masters of business, military or the circus and quote them.

And doing that would do two things. 1- Put the students to sleep, 2- Absolutely be nothing about me and the passion that makes me successful.

So my advice would be what works for me. Be a leader.

"Oh, right, that's real helpful."

You're right, that falls into the "pithy but true" category. The question is, how to be a leader? How to move from managing to being the visionary, the inspirer, the front of the charge or the wind beneath their wings.

For myself, it is following five personal principles. These are principles I've come to hold over my life and drive how I live my life and do my job.  It may not work for  everyone, but if I'm going to give advice, I should damn well have some passion for what I'm advising.

"So what are those five principles?"

Right, good question. Below are my five guiding principles and a short explanation. After presenting them at the PMI Silicon Valley annual symposium, in October of 2011, I began referring to them as the "Gorilla Equation," the five "x" factors that make a good managers. 

The Gorilla Equation

1. People, Not projects.

2. Communication is 100% of your job.
3. Process is a tool, not a roadblock.
4. There is no, one, right way.
5. All roads lead back to the customer

People, not projects: This is the foundation principle in the Gorilla Equation. Without this foundation the rest lack a structure to sit on. If I focus on helping the team become a high performing one, the team will do better. A better team leads to a better product and I firmly believe this combination will lead to a better world. 

I spend every day of my job trying to make myself obsolete by enabling the team and helping them grow.

Communication is 100% of your job: PMI says communication makes up about 80% of a PMs job. I say it's 100%. Think about what a project manager does. You'd be hard pressed to find anything that doesn't involve some manner of communication.  Not only is it 100% of your job, but you need to be adding value to every communication you are involved in. You are not an operator, you are more like the chief operation officer for your team. It's your job to facilitate all the communication and enhance it along the way.

Process is a Tool, not a roadblock: Don't ever let process take control of your project. If a process does not contribute value to the end user/ end goal, then look at dropping it,  streamline it, or focus it. Make sure your process is not subverting principle 1 or 5.

There is no, one right way: If I want to go from San Francisco to New York there are dozens of options (Different airlines, driving, train, cruise ship, even biking) and any one of them could be the right way for me, depending on my goals and constraints. Anytime you here "That's the way we have to do it" ask "Why?" If something has to be done, be open to if there is an easier way to do it. Inspect and Adapt.

All roads lead back to the customer: Where "People, not projects" is the foundation principle. "All roads" is the guiding mantra. Rooted in my original high tech job in customer support its been like that beacon in the night that lost ships yearn for. If you can't map what you are doing to some impact to the customer, then you should be asking why you are doing it.

Five principles, one result. Better me, better teams, better product, better world.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Gorilla Robot- All work and no play is bad for the PM

It was dark… very dark.

The darkness would have been complete, save for the blue-tinged glow coming from my monitor. With an annoyed sigh, I reached over and flicked on my desk lamp, restoring a moderate pool of light to my desk. I really hated it when the janitors turned off all the lights when they left. Didn't they know people were trying to work?

"I'm pretty sure that's singular not plural."

Suppressing a groan I peered into the darkness beyond my desk. "What now, Hogarth?"

His black fur made him all but invisible until he ambled into small pool of light given off by my lamp . "I was just saying I think it's singular. There isn't anyone else in the building."

"So?"

Hogarth gave a shrug. "Well it is 11:00 pm."

"And?"

"Most humans might consider that a reasonable time for no one to still be working."

I rubbed the bridge of my nose and desperately wished for my personal gorilla to make like a banana and split. "Why are you here, Hogarth? I've got another three hundred emails to process through and then I have the quarterly status report to work on."

"The quarterly that's due in two weeks?" He asked.

"Yes, I want to get an early start."

"At 11:00 pm?"

I looked up in annoyance. "Was there something you wanted?"

Hogarth nodded. "Oh, yeah. A new code of conduct was just put out by the HR monkeys. " He laid a vellum scroll down on my desk and carefully unrolled it to reveal three lines in elegant calligraphy (Leave it to the HR monkeys to go overboard on communications). I leaned over to read the new code of conduct.

1. You may not injure a human being or, through inaction, allow a human being to come to harm.
2. You must obey the orders given to you by human beings, except where such orders would conflict with the First Law.
3. You must protect your own existence as long as such protection does not conflict with the First or Second Laws.

I stared up at my gorilla in confusion. "Hogarth, these are Azimov's Three Laws of Robotics"

He nodded ever so sagely. "Yes, yes they are."

"But I'm not a robot, I'm a human."

He cocked his head to the side "Really?"

Meet Peet.

Peet's my horse. Or as I often think of him, my four legged stress relief valve. When Peet and I are cantering up a hill, at close to twenty miles an hour, the last thing on my mind is anything to do with work. In fact I learned early on that you don't even try to think about work when on horseback. If you let your mind wander, your horse can and will obligingly steer you into a tree (because you told him to when you weren't paying attention to your hands and legs).

I remember when I first got Peet. I'd never owned a horse before and could count on two hands the number of times I'd ridden one. (Now you might wonder why on earth I was buying a horse, but I learned a long time ago to listen to my incredible wife and this was another of those times I did.) About three months after I'd bought him, one of my co-workers commented to me how much calmer I seemed. Only three months as a horse owner and it had already had a profound effect on me. Now, years later, I find it hard to imagine not having a horse and being able to escape everything by saddling up and heading out on the trail for an hour or more.

If Hogarth and Peet have not explained my point well enough, let me quote James Howell's famous proverb.

"All work and no play makes Jack a dull boy."

Let's take a moment to examine Parkinson's Law, "Work expands so as to fill the time available for its completion."  As knowledge workers we live in the depths of this law day in and day out. I can come to the office at 5:00 am, work straight through to 8:00 pm and still be guaranteed that there will be more work for me to do tomorrow. I will never catch up. There will always be one more email, one more report, one more meeting.  Parkinson's Law will always fill any time you give it with more work.

So don't give it more time.

It's up to you to set the boundaries. It's up to you to realize that you can often be more effective, by doing less. Peter Taylor wrote two books on this entire concept, the Lazy Project Manager and the Lazy Winner, both of which I can recommend as worth the read.

Don't believe Peter? How about your eye doctor? Anyone who's worked with computers for any length of time has probably seen the recommendations to look away from your computer every few minutes. If you keep them fixed on the screen all day, you are exposing yourself to huge headaches and possibly wearing out your poor eyes so that they need glasses (or stronger prescriptions for those of us already spectacled).

At the end of the day I can't offer you any pithy words of wisdom or sure fire management techniques (learned from people far smarter than I). At the end of the day all I can do is say one thing.

"Go home!"

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

How much for that Gorilla in the window? - Assigning value to requirements

 

Hogarth shoveled another handful of popcorn into his mouth (Yes, gorillas like popcorn - read the right sidebar, go figure). He was sitting at the end of the table, size huge feet propped up on the table and looked as if he were thoroughly enjoying himself.

Which couldn't be said for me. I turned back to the discussion at the table, wishing a crack in the earth would open and swallow me up.

"Every one of them is a P Zero feature." said Tully, the junior product manager. Though I swear I could see Bob's lips moving as Tully spoke.

We were in the Icarus project's concept phase exit meeting.  Product management had just presented their list of requirements for Icarus. The entire list was up on the projector screen, two columns wide and in ten point font. I had surreptitiously taken a photo with my phone and was zooming in just so I could read the list.

"But which one is the highest priority?" Jake asked. This meeting was where engineering saw the requirements for the first time and started looking at what could be done. Feeling like I was in a tennis match, I let my eyes swing back toward the two product managers.

"All 100 features are must ship, they are the same priority."

I was starting to feel like I was witnessing the start of a train wreck and there wasn't a damn thing I could do about it.

"Look, even if we could do all these features in the release, which we can't, you still would need to prioritize them so you can flesh out the top of the backlog. None of these are good enough to start developing on." Jake was keeping his voice surprisingly calm.

Bob had apparently gotten tired of the ventriloquist act and spoke up. "Are you saying you're only going to estimate the top items?"

Jake sighed, shaking his head. "No, we can give you a relativistic estimate on everything, with this data. But none of these features is defined enough for the team to start work. I've got no idea what to start on in the first sprint." He laid his hands on the table, "Look, if you can't prioritize them then you have to do full user stories on all of them and I'll just pick which one to do first. That's fine by me."

"But we can't do that, it would take weeks to flesh out all these features, and besides the requirements might change."

Jake shrugged. "Then we need to find a way to rank order them. I can do effort estimates on all of them and just start on the easiest ones first."

Oh boy, Jake was playing hardball now. Bob leaned over his laptop with a pained expression. "The easy stuff isn't what the customer wants right now."

Jake leaned back. "Well at least we're getting somewhere."

At this rate, this was going to be a long meeting and it wasn't going to solve anything. Against my better judgment, I turned to cast an imploring look at Hogarth. Wiping his popcorn encrusted mouth with the back of a furry arm, he reached into the popcorn bucket and pulled out a deck of Fibonacci cards.

"It works for story points…" He offered.   

What do we do first?

Today we talk about one of the fundamental problems with product requirements. Last week's "Garbage In, Gorilla Out" focused just on the need for good requirements. This is important, vitally so. A well executed project, built on bad requirements is a bad product (Can you say HP Web Tablet? I knew you could)

The problem is, then what?

If I have one hundred perfectly defined features what do I do with them now? I can hand them off to the development team so that they can give me a level of effort (Story Points in Agile). That's great, but now I have one hundred perfect features with story points. I still don't know which one to do first.

Business value: What is the value of this benefit to the customer and/or  the business? This can also be asked in reverse, "what will it cost us to not implement this?" (Kanban tends to look at it from this view point). If you don't know what the value of the feature/user story then you don't know if it is more or less important than the next feature. You then end up in the model some old style engineering managers love. "Just give me the list of what you want, I'll figure out what I have time to build."

Technically perfect and customer flawed.

Apple has constantly focused on the value. Products they delivered did exactly what you wanted them to do (sometimes even doing things you didn't know you wanted, but now can't imagine how you would ever live without). Being a PC guy, this has sometimes been a hard pill to swallow. I've seen the exact opposite with PC products. "Do I really need 7mm instead of a 9.5mm hard drive? What I would really like is it if it included Bluetooth so I didn't have to have a separate set of headphones just for my computer." PCs have been really great at offering up new features that had no real infrastructure to use right away while lagging on basic,s like user interface.

Great, I'm sold already, how?

Ah and there in lies the rub. How do you figure out business value? Raise your hand if you've seen a product management forecast you believed in. Yeah, thought so. So if we have trouble figuring out how much we'll sell of the whole product, then how do we decide the value of a single feature/user story? Some companies have put together very elaborate procedures for this that practically call for a Ph.D. in math. Reportedly Intel has eighteen value "levers" used to evaluate not just projects but features in a project. Yikes.

Reaching into the agile pool isn't a lot of help either. While a whole blog of its own, the core issue with the most common estimating technique, Planning poker, is that it focuses on one feature at a time. And the problem with that is the human mind. Say I'm playing planning poker on a home improvement project. The user story is "As the home owner I want a blue exterior because it will make my house blend in with the skyline." Okay, painting the house. No matter how hard I try I'm going to be thinking about how many hours I'm going to need. When I flip over the 13 I've just mentally associated three days with 13. So of course a one day project is a 5, right?

When you evaluate each feature on its own, it is very hard for the human mind to not associate time with it.

So don't…

Steve Bockman developed an estimating process called "The Team Estimating Game." He and Agile Learning Labs have been using the game for years, teaching teams and companies this new way of estimating story points. Last year, Agile Learning Lab's maven Laura Powers realized that it could be used for assigning Business Value.

And?...

And with permission of Agile Learning Labs, I'm sharing their excellent game. After attending a Product Owner Training, I wrote down what I learned and have been using it ever since.

The Exercise: Take the defined user stories. These can be at any level of detail, but obviously it is better if they have some basic story decomposition done and they are clearly understood by the product owner and other business stakeholders. It is best to start with no more than twenty stories. After completing the game with these stories, future stories are then played against this initial set of stories. This makes subsequent evaluation go quicker and allows for estimating the value of hundreds of stories.

Phase 1: The first step is to estimate their value relative to each other:

1. Place Story Cards in pile on table.

2. First player places top card on playing surface.

3. The second player places the top card on playing surface relative to first card. They decide if the card is worth more business value or less than the original story.

4. The third player then has several choices. They can either:

* Play top card from pile, placing it on the field where they think it fits (moving other stories to fit between stories as needed), or

* Move a card on the playing surface from one location to another, or

* Pass

Note: When placing or moving a card the person conducting the action typically gives a short explanation. So long as it does not derail the conversation, team discussion is encouraged. The Agile Coach/Facilitator monitors this and if a conversation starts to deep end they ask “So whose turn is it now.”

5. Repeat Step 4 until

a) no more cards remain in pile, and

b) no player wishes to move a card

At the end of the first phase of the game you have a single, linear line of user story cards. The cards to the left are deemed the least valuable and the cards to the right are the most. No overlap of cards occurs at this time.

Phase 2:  Having ranked each story to create a single ordered list, it is now time to assign a value rating. 

Start with a standard deck Fibonacci numbers. Typically up to 144 is more than sufficient. Add to this the (-) card, to represent stories that have no business value. Note: Business value may not represent the only value in a project. You may have regulatory concerns, infrastructure concerns, etc. Whenever possible try to assign a business value to the story. This usually requires looking at the operational This may require asking the “what do we lose if this is not here?” Zero business value should be truly something that will not be missed in anyway if it is not in the product (“No one really wants a wood stove in their car”).

1. Place the (-) card to the left of the left most story. Anything that moves left of this card will be considered of no business value.

2. Place the “1” Card over the left most story. This story now represents your baseline that all other stories are measured against.

3. Hand the deck to the first player. The player takes the “2” card from the deck and then looks at the stories to the right of the “1” card. They place the card at the story they think is twice as valuable as the first story.

4. The third player, then has several choices. They can either:

* Place the “3” card to the right of the “2” card where they think a story is either three times more valuable than the first story or is one and a half times more valuable than the story with the “2” over it.

* Move the “2” card left or right to where they think the user story is equal to twice the value of story one.

* Pass

Note: Fibonacci Cards are placed on the table in order. You do not place the “21” card until the “13” card has been placed.

Note: Any stories between Fibonacci cards are assumed to belong to the Fibonacci number to its left. So if there are three stories between the “5” and the “8” then it is assumed those three cards are considered a value of “5.”

5. Repeat Step 4  until
1. All stories have an assigned value (not all Fibonacci cards must be played), and
2. All players pass on adjusting any of the Fibonacci cards.

Concluding: At this point any “orphan” cards, those between Fibonacci cards, are then moved into columns below the Fibonacci Number to their left. You are now left with a number of columns of cards (there is no right number).

The exercise is done. Capture the value for each story in the appropriate manner.

Important Note: The Coach/Facilitator should watch for ranking based on cost. This exercise should be conducted with the “infinite budget” concept. “Don’t worry about how hard it is to build right now, just worry about how valuable it will be.”

Important Note: If you are planning to have these stories estimated for cost (time to develop), it is recommended that the business value not be shared with the team doing the cost estimating. This prevents the cost estimating being skewed by the Business Value.