Category Archives: Project Management

The Gorilla Pareto: Agile Adoption Anti-Pattern

Posted on by
3

80-20_TeamsIt seemed like a good idea at the time. That’s what I kept trying to tell myself and I dragged my way up the hallway to my office.

When the VP had come to my office and told me he wanted me to go help the Perseus team, kick off an agile transformation, I was thrilled. We’d been having some really good luck agile on the Icarus project and the VP wanted to see if we could extend that farther. The guys on Icarus we’re awesome, true rock stars all of them and I know that helped a lot. Still I saw no reason why the Perseus project couldn’t get some benefit from agile. 

I felt like a Spartan who came home without his shield. Not only did I fail, I was massacred. 

“You’ll be more motivated, more empowered,” I said. 

To which someone on the team replied, “We’re plenty motivated, we are doing the work we want to do.”

“The scrum master will be tasked with removing your impediments, making work easier,” I said. 

To which someone on the team replied, “If the company doesn’t fix blockers, then we work on something else.”

“You’ll be recognized for your expertise.” 

To which someone on the team replied, “So? We must be recognized, the company hired us. We gonna get paid more if we do agile?”

“You get to decide how its built, instead of being told.”

To which someone on the team replied, “Seriously? We don’t listen to product management anyway. We’ve been building it our way for years.”

“Status reports practically write themselves. The burn down is your status.”

To which someone on the team replied, “Project management writes the status reports. Besides, it’s not like anyone pays attention to them.” 

I slumped against the door to my office and gave a deep sigh. Of the entire team I think only one or two showed any real interest. One was a smart kid probably no more than three years out of his masters and the other was the overwhelmed and frustrated development manager. 

“Hey,” a voice called from inside my office. I looked in to see Hogarth abusing my office chair with his bulk. He was holding up the banana I’d picked up from the fruit bowl this morning. “You don’t have any Lady Finger bananas? Heck, even a Goldfinger or Lacatan would be great.” 

I strode into my office, extremely not in the mood to deal with my gorilla conscience today. “Hogarth, it’s a banana. You can have the yellow kind or the green kind that’s not good unless cooked.”

“Plantain” 

I stopped, “What?”

Hogarth got a professorial look, indicting a teaching moment was coming. “Plantain, that’s the green kind and not technically a banana. It’s Musa paradisiaca, while dessert bananas are Musa sapientum.” He held up the banana, “This Musa sapientum is a Cavendish, a Robusta to be precise. Your generic everyday banana. Okay for putting on cereal or peanut butter and banana sandwiches, just not the connoisseurs’ banana.”

“You’re telling me bananas come in more than big, little, green and yellow?” I asked. 

He nodded “Yeah, I think it’s like the parrot principle or something. Eighty percent of the bananas produced and exported are a variety of Cavendish.” He held up the banana by way of demonstrating. 

I blinked in confusion, “You mean the Pareto Principle?” 

Hogarth shrugged, “Yeah, that’s it. Some Italian economist right?” Hogarth cocked his head, “too bad they don’t have some Pareto rule for people.” 

Yeah too bad, that would explain a lot of things….

Hey, wait a minute!?! 
Why do some developers hate Agile? 

Note: The goal of this blog is to generate critical thinking on this subject, not to point fingers.

A lot of the popular agile marketing pumps up how much developers will love agile. How your development teams will be the ones fighting for it, championing for it or even doing it behind management’s back. Sure, I’ve met these people. Most of them work for boutique shops or start-ups. Unfortunately I find in enterprise software companies that these agile champions are often in the minority.

This has long created a cognitive dissonance in me. I know and understand in my soul that the values and principles of agile promote not only a more effective and productive workforce, it also produces happier, more engaged people. In short, I support agile because I think it will lead to a better world.

So why is there so much resistance from those it was intended to directly benefit? Then it hit me. I had a realization, an epiphany even. Agile is only revealing the underlying truth, one that many in the work force would love if it had never been undiscovered.

In Traditional Development, the majority of the work is being done by the minority of the people

The Pareto principle (also known as the 80–20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes. 

Anyone whose spent even a couple of years in high tech will have heard of the 80-20 rule. I hear it most often in the “80% of our calls are from 20% of our customers” or “80% of our business comes from 20% of our customers. Reaching to Wikipedia we find that the Pareto principle has several common business corollaries.

  • 80% of a company’s profits come from 20% of its customers
  • 80% of a company’s complaints come from 20% of its customers
  • 80% of a company’s profits come from 20% of the time its staff spend
  • 80% of a company’s sales come from 20% of its products
  • 80% of a company’s sales are made by 20% of its sales staff

    From <https://en.wikipedia.org/wiki/Pareto_principle#In_business>

Notice the one I bolded? Well yeah, I bolded it so you would.

What happens if you replace “sales” with “code” and “sales staff” with “development staff”, what do you get? The Pareto principle is arguing that 80% of the code developed is coming from 20% of your software development team. Those rock star coders? The ones management frets about what will happen when they leave? Yeah, they should worry. Because these rock starts are not just good at their job, Pareto argues they are probably doing much more work than the majority of the team.

Then along comes agile to shine a bright scary beacon on this reality. Suddenly bringing the coders into the light and making in crystal clear who is doing the work and who is not. When the team is reviewing work every day, and planning every week or two it quickly becomes apparent who is doing the work and who is not.

This is a tough subject and not likely to be wholly popular. No one wants to be told “hey, you’re a slacker!” I know, I’ve been exactly in the shoes of an agile resistor. I once told a room full of people “you’ll pry waterfall from my cold, dead hands.” And reflecting back now, I can say one of the things I feared was how much attention it would put on my own work.

So I can first hand the feeling of that scrutiny on your work is not unlike being a cockroach caught in the light. Close to twenty years ago I was in a job where I was doing okay, just okay. I wasn’t a rock star by any means. I was, however, the only person with a specific skill set and for a variety of reasons I didn’t work as hard as I could have. Then a new person came along. They knew my special skill set and tackled work with a wild abandon. The person was also incredibly nice and personable which meant it was hard to even dislike them. They were just doing their job and doing it well. I still felt like a cockroach caught in the open.

There are plenty of hard workers out there, that are not in the theoretical 20% of the people doing 80% of the work. And the painful fact is there are also a percentage of those workers who are knowingly under performing. The 2014 Gallup poll again found more than 15% of workers are actively disengaged in there jobs.

 

Want another interesting thought exercise? Let’s reach into the agile bag of data for a second. A common statistic you hear, agile proponents, is more than 60% of product features are used rarely or not at all. So if 80% of the work is done by 20% of the people and only 40% of features are ever used, does that mean our teams are 80% too big? I have seen some blogs of late that argue a super-star team of ten can build any product a team of 100 can and do it better and faster. Taking the Pareto principle into account, they may not be far off the mark.

What’s the call to action?

As I noted at the start of this section, I am not seeking to point fingers. I’m seeking to generate thought. I don’t have a call to action, I don’t have a solution.

I think I know a reason why some enterprise software coders are resistant to agile. However if they don’t want to be more productive, shining a bright light on them isn’t exactly going to make them happy.

I suppose we could use this data to convince executives to adopt agile more. If we can show them who are the real producers, they can either shrink their work force or hire more of the 20% who do the work. I’m not sure that’s going to be the best use of this data by an agile coach. It might be useful for agile consulting firms in their sales cycle.

As an agile coach, trying to find a way to encourage teams to adopt agile, it’s not immediately helpful. I’ve got a symptom now. What I don’t have is a cure.

How do we make everyone part of the 20%? Can we?

Gorillas don’t juggle – The Sins of Multi-Tasking

Posted on by
1

“Yeah hang on a second there Pete.” I shifted the phone to my other ear so I could grab my cell phone. “Go on, I’m listening.” I brought up the screen on my cell phone to see a text message from my wife asking if I’d done the research on website design I’d promised. Setting the cell phone down I tried to shift my desk phone back to my other ear. Only to drop it on the desk.

 

Scrabbling it up I tried to sound nonchalant, “Oh sorry, wind caught my office door.” Pete started talking again so I hit the mute button and then put the phone on speaker so I had two hands free. While Pete continued on about the project status, I think Bill was actually asking some questions now though it wasn’t important, I brought up my web browser and  quickly shifted it to my second screen so it wouldn’t block the web session I was hosting. I needed to get my wife an answer. I could do that while the conversation went along, just had to keep it on track.

 

“Yeah, Pete, that’s a good point. Can you talk about how you’re going to…” Why were people talking over me like I was on… Oh right. I hit the mute button and steered the conversation back the right direction.

 

Mute back on I dove into the website I had pulled up.

 

Why was the phone ringing and people talking at the same time. Oh, cell phone. “Yeah, honey I’m looking at it right now.  What? No, hang on.”

 

Unmute, “Yeah, Bill can we get a summary of the Icarus work?”

 

Back to my wife, “No, I haven’t had a chance to do anything, I’ve had thing to get done first.”

 

“What, no, Bill Icarus is the highest priority I, uh, had someone come into my office. Please proceed.”

 

Mute.

 

“Honey, what? No, I understand how important this is. Hang on.”

 

Unmute “Yes, Pete the website will be ready on June 12.” Mute

 

“Now honey,” Oh crap, did I just.

 

UnMute, “I mean the software release will be ready on June 12, sorry about that.”

 

And before I could hit the mute button a massive hair covered hand reached over me to hang up my desk phone. Before I could protest, another similarly hirsute hand plucked my cell phone from my ear. “Mrs. BC, he’ll need to call you back. Oh, I’m good, thanks. Just doing a little intervention. Yeah, he’ll be better. Soon.”

 

“Hogarth!” I snapped, trying to snatch the phone out of his hand. “I’m working here!”

 

My gorilla drew back across the desk and settled into my guest chair with a creaking groan of protest from the chair. “Really,” he said, “It looks more like you are juggling, badly.”

 

“Wha…” I tried to come up with something sharp to say, but the image of dropping my desk phone wouldn’t leave my mind.

 

Hogarth set my phone down on the desk. “Think of it this way, ever seen a juggler try to eat an apple while he’s juggling?” I gave a mute nod and Hogarth continued, “Yeah, it’s a mess isn’t it? The worse one I ever saw was the guy juggling one apple and three eight-balls.” Hogarth shook his head, “I hope he had a good dental plan.”

 

Ouch….

 

MULTITASKING IS NO TASKING

 

Let’s do a little exercise. You’ve got a smart phone, right? If you don’t I’m betting you have a watch with a second hand. If you have both, pick your poison. You’ll also need a piece of scratch paper and a pencil or pen.

 

Ready?

 

For the next fifteen seconds I want you to write from number 1 to as high as you can get in that time. Ready? Go!

 

Okay, how far did you get? Not bad, huh?

 

Another fifteen seconds now. This time I want you to alternate between numbers and the alphabet. 1A2B3C etc. Ready? Go!

 

Wow… didn’t get as far, did you?

 

And these are easy tasks. Try a third time only this time start at number one and the letter Z. Go forwards on the numbers and backwards on the letters.

 

Yeah, didn’t go so well did it?

 

Multitasking is not really multitasking. Instead what we are doing reminds me of the early days of main frame computers. We have one CPU, our brain, which can only do one primary task at a time. We aren’t multitasking, we are switch-tasking. Like the main frames of the 1960s and 70s where the CPU would give each user a slice of time and constantly rotate. Only, we are not computers and that means we can’t switch tasks instantly like those old IBM main frames could.

 

<iframe width=”560″ height=”315″ src=”http://www.youtube.com/embed/ARJ8cAGm6JE” frameborder=”0″ allowfullscreen></iframe>

 

The human brain is not capable of focusing on more than one primary task at a time. Yes, we can do a lot of secondary things (breathing, peripheral vision, etc.), we can only face one focused tasked at a time. We might be able to switch quickly from task to task. We just won’t be nearly as efficient as focusing on a single task. The cost of switching tasks high.

 

Some studies say we can take up to fifteen minutes to get back on track after being interrupted. If we are multitasking, we are interrupting ourselves.

 

The same thing applies to teams, that applies to people. If your team is only working 50% of the time on your project, the reality is they are probably only working 40% on your project as they have the overhead of switching back and forth between your project and other projects. The more projects they are working on, the less time they can devote to each project.

 

Jim Highsmith, in Agile Project Management gives a great example of a team doing multitasking.   In the first example, the team switches between three projects, one day on project one, two days on project two, etc. In the second example, the team works on project one until it is done, then moves to the next project.

 

In the multitask example, the first project completes on day 48 and all three projects are done on on day 52.

 

In the sequential projects, project one is done on day 20 and all three projects are done by day 36.

 

I’m no math major and I can tell sequential is a better idea. The first project is done in less than half the time and all of them are done in two thirds the time.

 

Multitasking, all it does it make you look busy.

 

Results matter.

 

Do the math.

 

 

Gorillas don’t need authority to lead

Posted on by
1

“What do you mean you’ve got to go? We’re three weeks behind schedule we need all hands on deck.” I was gripping the phone so hard I was sure I was leaving finger prints in the plastic. “No, no, no. We went over this. If we can just get through this release, we can all take some time off. We’ll even get comp time.. Uh huh… yeah. Okay I’ll talk to you when you get back.”

I slumped back into my chair and stared at the ceiling. My half hearted attempt to get the phone back on its receiver without looking only resulted in the phone falling to the desk. I left it there and continued to stare up at the ceiling. This was the third person on the project to take a vacation this month. The project was already an aggressive one and I’d under estimated resources so every day was critical. At this rate we’d be red and slipping by the end of the week.

I heard the distinctive click of the phone being placed back on the receiver. Great, just what I needed. “Go away Hogarth.” I didn’t hear anything. Of course I don’t think he made any noise when he didn’t want to. Still I knew he was still there. He was staring at me right now. He was probably thinking about how much this conversation sounded like my last project. He was staring at me now. He was just waiting for the right moment.

“Augh!” I threw my hands up as I sat up in my chair. Coming up right my eyes fell on my gorilla. Hogarth just sat in the chair across the desk and stared at me. I hate it when he does that. “Okay, okay, so I didn’t get them the time off after the last launch. We had that special project pop up and we needed everyone on it right away. And we couldn’t have a party because we were in the third quarter belt tightening season.”

Hogarth nodded. “Uh huh…”

“Hey don’t you start!” I snapped. “It shouldn’t even matter, I’m in charge of the project and I said it needs to be done. They just need to pony up and buckle down.”

It’s easy to forget that the arm span of a gorilla is considerably greater than we humans. I was reminded when a leathery palm reached from across the desk and smacked me upside the head.

“Ow.. Hey!” Hogarth was still sitting calmly in the chair opposite me. Had I not just witnessed (and felt) his hit to my cranium it would have been hard to imagine he had ever moved. “What was that for!?”

I think Hogarth may have actually rolled his eyes. It was hard to tell with the bushy eyebrows. “Fool me once, shame on me. Fool me twice, shame on you?”

I blinked. “Seriously?” I said. “You’re going to start spouting old English proverbs at me now? What’s next?”

“Joan of Arc.” he said.

Okay, now he was just playing with me. Just trying to put me off balance before he gave me the real message. Right? Suddenly the same leathery palm that had so recently reached out and touched me came up again. I started to flinched, until he turned the hand towards him and gave his chest one sharp beat.

Okay, maybe he wasn’t’ playing…

“We can agree she saved France from destruction?” He asked.

I nodded.

“And we can agree that at the time, the thought of a woman, much less a girl leading an army is pretty absurd?”

Again I nodded.

“And when she started, did she have any authority?”

I shook my head.

Hogarth nodded. “That’s right. What did she have. Why did people follow her?”

“They had faith in her. They thought she was sent by god.”

Hogarth nodded. “And what underlies a belief like faith?”

Hogarth knew I didn’t know the answer. He wouldn’t have asked the question if he thought I knew it. So I just waited.

“Trust.”

Trust…

It doesn’t matter if you’re the president of a nation or the janitor cleaning the offices. Without trust you can have all the authority in the world and people won’t go that extra mile for you. Without trust you won’t be given the opportunity to excel and grow. You might get them to do what you tell them to do. Will you get them to do it with passion? You might have your job, will you keep it and grow?

And with trust, you can lead a nation’s armies when you are nothing more than a slip of a girl.

You’ve got to ask yourself, what do you want to work on improving? Authority or Trust?

Which is going to go farther with your team?

Sometimes a Gorilla is just a Gorilla

Posted on by
1

clip_image001

“You’ll thank me for this. It’s going to make you so much more productive.”

Jake eyed the spreadsheet dubiously. I suppose I could understand his reticence. At first glance the Systematic Total Universal Program Iteration Document was a bit of an eye chart. I hadn’t understood it really until I’d taken the five day intensive training. But hey, now that I was trained I knew this was the absolute best thing I’ve ever seen. Ever!

“And I have to update this every week?” he asked.

I shodded my head. (You know, when you start to nod your head and then shake it no?) “Well that tab yes, click this other tab for the daily report.”

Jake complied, his eyebrow crawling into his hairline when he did. “This… This is a daily report.”

I nodded enthusiastically. “Uh huh, we’ll always know where the project is now.”

Jake closed his laptop and gathered up his stuff. I could see he was in a daze. Probably thinking about just how productive this was going to make him, once he finished the training. As he walked past me I heard him whisper ,”Yeah, this is definitely stupid.”

I held up a finger, “It’s pronounced ESS-tup-Id .”

Jake stopped for a moment. Then shaking his head, he kept going.

I tugged at my beard. “Well that was weird.”

“Weird in that he didn’t feed you his computer, or weird in that you thought that actually went well?”

Why did he always have to come and ruin my mood? “Hogarth, I don’t need your help. Things are going just fine. The new process is going to be a wonder.”

Hogarth’s looming form pushed off the wall and made its way over to the conference table. “I was more thinking blunder, but hey they do rhyme. “

“Blunder? Have you been smoking banana peals again. What are you going on about?”

Hogarth settled into a chair, easing back slowly as it desperately protested. “I’ll have you know I was drying those peals for a science experiment.” He waggled a leathery hand at me. “You’re playing with your shiny new toys again.”

“So?”

Hogarth leveled his deep brown eyes at me. “If it works, don’t fix it.”

Huh…

SOME DAYS ALL YOU REALLY NEED IS A SCREWDRIVER

Way back in 2009 I introduced folks to PIG, the Process Inflexibility Gorilla. In that blog I gave folks the screwdriver argument , which is a useful analogy for why you want to be able to support more than one process, tool or way of thinking.

In a nutshell, the screwdriver argument is:

“If you have the world’s best screwdriver and you’re locked in a room with lug bolts, all you have is a pointy stick.”

And flexibility is a good thing. It’s a key tenet of agile and many leading management techniques. I’m all for flexibility. I’m all for trying something new and innovative. And I’m also aware that I suffer from the all to common failing of…

Red Ferrari Sports Car

“Oooooh, shiny…”

Sorry, where were we? Oh, right, shiny. Back in the 90’s there was a US SitCom called “Home Improvement.” In the show, the lead character (Tim Allen) was a bumbling suburban dad with a TV Show where he was a tools “expert.” Without fail, if he got a hold of a new tool, he had to use it and he had to use it right then. Even if it meant he ended up dropping a crane load on his wife’s classic car.

New toy syndrome can be the death knell of many a good project. The latest fad comes along (we talk about fads in “Agile- A Gorilla Four letter word?”) and off the company goes. Who moved my cheese, Trust Courses, Yell Thereby, African Expeditions, Survivor Board Room, you name it, we’ll try it. All in the blind attempt to find a better way. Only do we need a better way?

If the orders are shipping on time, order placement productivity is high, the customer is happy and the company is doing well, do you really need to shake everything up and put an entirely new ERP system in? Probably not. And yet I’ve seen it done. A complete replacement of a tools system because the new tool would be cheaper, so what if it doesn’t have all the features we need right now, their professional services said they can build us what we need.

New toy syndrome can strike our projects as well, though sometimes it can be old toy. I worked at one company in a division that had been acquired from the outside. The division was acquired because they understood a specific target market and knew how to build and sell to that market. The buying company then proceeded to try and impose its monolith process on the new division. A process designed to build technology that took from 2-3 years to develop was laid on top of an organization that regularly went from concept to ship in less than six months. And then the big company was confused by why the new division was doing so poorly.

You know, I could go on. But in the end, I think Hogarth summed it up perfectly.

“If it works, don’t fix it.”

Talking to gorillas, I’m Joel BC

The Gorilla Hero- Project Management’s Super Power

Posted on by
Reply
“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 CERTtraining 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

Gorilla Ethics: Is that your banana or mine?

Posted on by
3

Have I ever mentioned how much I loathe team building exercises? Not the real one, no.  The ones that take cut-throat competition and slap a happy veneer over it to call it team building?
I squinted through the sunlight, trying to see where Sue was in the obstacle course. It was one of those big inflatable things that look like some swim float on steroids. She was struggling through inflatable tire rings about halfway through the maze. Meanwhile our opponents, from accounting, were just clearing the exit with their second to last man. And I was standing helplessly at the starting line, waiting for Sue to reach me so I could take my turn in the inflatable torture chamber.
The referee (okay the high school kid overseeing our event) came up to us and asked Monica how many were left to go on our team. She turned to look at Mr. Huggle . He looked over at me and then back at the ref, “Just him.” I looked at Mr. Huggle in confusion. He was the anchor, he’d called it at the start of the event and as the boss, he got it. He looked at me and gave a short shake of his head, the meaning unmistakable.
And then I didn’t have anymore time to react. Sue was running towards me. No matter what, I needed to do my personal best…
I walked into the  air conditioning of the sports center’s cafeteria. I made a beeline for the coolers full of beverages and yanked a bright blue sports drink from the ice. Putting the bottle to my neck I let its cold wash through me as I closed my eyes and tried to let go. Mr. Huggle had never run the obstacle course and because I’d run my heart out, we’d “beaten” accounting and “won” the obstacle course.
Yet, in the end it hadn’t mattered. They had already trounced us in the soccer shoot-out and then went on to annihilate us in ultimate Frisbee. So in the end, accounting won the overall competition and all I had for my experience was a lingering unease and a sweaty t-shirt.
Finally I gave a shrug and took a long pull from the sports drink. I had to let it go. It’s not like it was a big deal and we didn’t win anyway. So what if Huggle cheated?
<Clunk… Slide…. Clunk… Slide…>
Fearful of what the sound could be, but knowing full well what it was, I turned towards the door. He was silhouetted in the sunlight, his black form even more indistinguishable than normal. He was moving strangely, a waddling shuffle, almost like he was wearing…
“Hogarth! Why are wearing skis?”
Hogarth shuffled across the room his skis knocking over a couple of chairs the process. Plucking a banana from a fruit bowl and taking a bite from the unpeeled banana he chewed on it thoughtfully for several seconds. Finally, just as my patience was about to boil over, he turned to me and said. “To go down the slippery slope of course.”
“What slippery slope? It hasn’t rained in weeks!”
My gorilla gave a shrug. “The slippery slope that starts with fudging a team building game and ends with a Bernie Madoff sized Ponzie scheme.”
I threw my hands in the air in disgust. Stomping to a chair, I flung myself down and took a long pull on my sports drink. “Hogarth, it’s not the same. It’s light years difference between the two.”
Hogarth nodded, “You’re right, the difference is vast. And you’re wrong, it is the same. That’s your problem.”
“Huh?”
My gorilla looked me right in the eyes and spoke. “There is no such thing as black and white only shades of grey. The secret is knowing that and always questioning what you do. If you’re always checking to see if you’re off course, you’ll get back on course a lot faster.”
Ethics- In this post Lehmans, Enron, Madoff era you can’t go a week without some kind of news article about ethics. Whether it is decrying a lack of it, tips for being better, passionate arguments for the use of it or even unethical advice on how to fake it, ethics has become a major component of our professional lives. This isn’t the three martini Mad Men era of business (if that ever really existed) where anything goes to close a deal. This is the era of the always online internet where what you said ten years ago is still floating around on some Alexa server. PMI has made ethics an integral part of its certification process, as had many professional organizations.
We all know it is right to be ethical, we all know what it means. Google summed it up in their corporate motto “Don’t be evil.”
Hey, Google! How’s that working out for you?
The world has become a lot murkier in the 21st century. The clean and crisp lines that had Superman as good and Lex Luthor as evil have given way to hero’s like the Dark Knight and villains  the Libyans throwing off their “legal” government.
Where is the line now? If there is not black and white, then how do we know if we’re on ethical ground or a quicksand pit of corporate malfeasance?
Unfortunately, I don’t think there are any magic bullet on this. In the example above, you risk the wrath of your employer if you point out he’s cheating in a simple game. Is it unethical to stay quiet? At the other end of the spectrum, if your boss is embezzling seven figure amounts from the company, it’s pretty clear cut that you should do something.
But those examples are like night and day!
Yes they are. The question is, what’s the difference between night and day? The answer is about one minute.
There isn’t a magic formula to tell you when you’ve gone from skating the edge to full on breach of ethics.
The secret is to always be asking yourself if you’ve crossed that line. Just as the courageous man is a man that knows fear but does it anyway, an ethical person is one who is constantly examining their own actions.
At the end of the day, there is only one person who can tell you if you’re being ethical or not.
Look in the mirror.
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

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

Posted on by
2

Coachin Agile Teams

 

“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

How to be a Gorilla Manager: In five easy steps

Posted on by
1

 

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.
  1. Communication is 100% of your job.
  2. Process is a tool, not a roadblock.
  3. There is no, one, right way.
  4. 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

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

Posted on by
4


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!”

 

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

Posted on by
Reply

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/orthe 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.
  1. First player places top card on playing surface.
  1. 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.
  1. 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.”
  1. 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.
  1. Place the “1” Card over the left most story. This story now represents your baseline that all other stories are measured against.
  1. 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.
  1. 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.”
  1. Repeat Step 4 until
    1. All stories have an assigned value (not all Fibonacci cards must be played), and
    1. 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.