The Gorilla Pareto: Agile Adoption Anti-Pattern

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


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

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?

Deep Gorilla: To Succeed in Agile, Follow the Money

Deep_ThroatDarkness threatened to swallow me whole. The elevator doors had opened up on a scene right out of a classic horror film. The underground parking garage was plunged into the depths of darkness. Light was limited to a few lights pouring out pitifully small pools of illumination. The scattered light contributed to making the darkness even darker. Facilities was working on the “intermittent power issues with all diligence” but that didn’t change the fact that our parking garage currently resembled a set from some bad horror thriller.

Just like my mood.

Oh, sure, the Icarus team was doing awesome. They’d taken to scrum like a politician to a fundraiser and their performance was amazing. As a proof of concept it had been an earth shattering success. As a catalyst for change, it had run straight into a brick wall of resistance. “Oh it worked fine for a small project, but it will never work on a real product.”

It was time to throw in the towel. I’d given it the old college try and carried the water. Now it was time to take my marbles and go home….

The distinctive click of an iPhone unlocking and the sudden glow of the screen revealed the dark outlines of a figure. Cloaked in the inky blackness and wearing dark clothing, It was difficult to tell where the figure left off and the darkness began. He had an almost looming presence, as if he were greater in size than me. Greater in size than any man. Wait a minute, was that a black coat, or that was that fur?


My gorilla lifted his iPhone to lips, the glow of the screen lighting up half his face and plunging the other side into deeper shadows. “Shhh, no names. We’re you followed? “

“Followed, what on earth are you talking about?”

Hogarth leaned back and turned his head from side to side scanning the darkness of the parking garage. Apparently satisfied there was nothing in the nothingness , he looked back at me. “If Percy knew I was here it would be bad for both of us.”

“Percy?” I wracked my brains trying to think of anyone in the company named Percy. “Wait a minute, you mean that Elephant you play poker with?”

Hogarth nodded, “Percy Liddy, he’s accounting’s Elephant in the room. His skin is so thick, nothing can get through to him. We were at a company once and the stock fell ninety-five percent in four hours. He just stood there, unmoved and perfectly calm. One of the monkeys from legal asked him what his trick for not panicking was. Percy responded that the trick was in not minding.”

“Hogarth, what are you going on about? I’ve had a long day and I just want to go home and drown my sorrows in reruns of Gunsmoke.” That’s all I really wanted to do. I was exhausted and tired of running head first into the brick walls of agile resistance. The company executives just didn’t see the value. It didn’t match their vision of the world and so it didn’t have a chance of succeeding. I was stuck, completely stalled, I had no idea who to talk to that would actually listen and could support an agile adoption.

“Follow the money,” Hogarth said .

I blinked at him. “What do you mean, follow the money?”

His bucket sized head gave a shake, “I can’t tell you that.”

I puzzled at what he had said. Follow the money. Besides being a way over used movie quote, what the hell did it have to do with anything. Then I understood. Okay I understood what he meant, I didn’t understand why. “You mean I should talk to Finance? Are you crazy, they pinch sawdust just to make more pencils.”

Just then Hogarth’s iPhone turned off, plunging our corner of the garage into total darkness. A few seconds later, from even deeper in the darkness I heard his voice whisper, “Just follow the money.”

Shaking my head I turned on my own iPhone, to light my way to my car. Accountants as the key to going agile, was he serious?


Crack the shell on your average enterprise class company and you’ll find so many agile antibodies if could overwhelm even the most robust agile coach’s immune system. Once you move past the small company, you start running into all sorts of adoption anti-patterns. Enterprise companies have been doing things the way they have been doing them for so long that inertia will keep them going for the next century. Without some way to show a tangible benefit, that makes sense to the C-Suite executives, we are going to continue to run into challenges at the higher end of corporate mindsets.

Pat Reed and Walt Wyckoff may have just given us the tools to break down the walls around the C-Suite. I attended the July session of the Bay Area Agile Leadership Network. There, Pat and Walt presented an Agile Accounting Model: The key to Enterprise Agile. I knew of Pat and had attended a talk of hers early in my agile journey. So despite being a failed art major, I confronted my fears of finance and went to see what I could learn. I’ve spent the last decade working in Enterprise class companies and I’ve seen first hand the challenges of trying to take agile from a tolerated experiment to the accepted way.

I admit I was dubious. I also admit a lot of that doubt was tied up in my own lack of finance knowledge. In some industries, project management has its hands all over the budgets of their projects. In my entire Silicon Valley experience, I’ve never been in a company where budgets and project managers ever had more than a passing acquaintance. I wasn’t alone in the room either. Basic concepts like Expense versus Capitalization are things most of us understood, but only just.

It wasn’t until the break out exercises that my Aha lights started going off. Working with Walt on how to explain the benefits of agile to accountants, we made a break through that the same explanation used to the accountants could be change the minds of the C-Suite.

Again, I’m no accounting genius, so bear with me here.

First off: Expense vs. Capitalization for dummies, by a dummy- Expense means you have to subtract that money from your balance sheet right now. If the project expense is three million dollars, that’s three million less profit for this quarter. Capitalizing allows you to spread the cost over months or even years. IT does this with computer hardware all the time. You don’t drop $100K for a server on the Q3 bottom line. Instead you divide the cost over the life of the server. So a server expected to last four years costs the company $25K a year, for the next four years. (Go check with a real finance person on this before taking it to the bank.)

Now to the benefits:

You can capitalize your Product Management (And more of development and deployment):

In a standard Waterfall lifecycle, everything that happens before coding starts (officially starts with the project commit)and after it ends, is considered an expense. Only the direct development effort is considered a “material” part of the project and can be capitalized and then only after it ships.

In agile, design and development are often tightly inter twined. If you are making proof of concepts then you can capitalize. If you’ve read Lean Startup, remember the guys who started the smart concierge service. Now think about the fact that they could start capitalizing their product the minute they had that first paying customer. This was months before the first line of code was ever written.

Agile can let you release more often. This allows you to start your capitalization faster.

Instead of releasing once every eighteen months, a successful agile can be shipping customer releasable product as fast as every month. You can start capitalizing faster, so you spread out your costs faster.

But wait, Enterprise customers don’t like frequent releases. And what about proof? You have to convince the accountants you can really ship.

First off, there is almost always one customer who will take your release. And all you need is one. So long as one customer takes the release and puts it into production then you have a shipping product and you can start your capitalization.

As for trust, it’s not a quick road to make a major change. Go to accounting right now. Tell them, “In the next twelve months we’ll make a shippable release every quarter and we’ll find at least one customer to install it. A year from now, we will come back to you and ask that we be allowed to Capitalize our development process from the start of Sprint 0.” In other words. Show them the money first. Prove you can walk the walk.

It can allow you to Capitalize your services

I didn’t get this one as fully as the other two. Ron Lichty, an agile coach and author of “Managing the Unmanageable”a soon to be released book, raised this and by the nods from Walt I know it made sense. With so many companies offering professional services (consulting) along with their products, this could be a huge win.

A word of caution: Beware the dark side.

Okay, so let’s go back to that Lean Startup use case. They haven’t written a single line of code. The product doesn’t exist yet. Instead they are manually doing everything their automated concierge service will eventually do. The CEO and CTO meet every week with their one customer. And yet they could capitalize all of this, spreading out the cost of coming up with this product over several years.

If we give Wall Street new and creative ways to report profits, we will also have to be very certain we instill in the C-Suite the rest of the values of agile and Stoos. If we don’t, we could end up at the wrong end of a shell game that makes Enron and Bear Stearns look like table stakes at church bingo night.

Umm, I’m not following you.

Yeah, what he said, only I don’t trust your data.

Fair enough. I’m not sure I followed it all either. I’ve since started watching Khan Academy’s videos on Core Finance, to raise my own knowledge of basic business accounting. Don’t take my word for it.

Hear it from the Speakers: Pat and Walt will be presenting their findings at Agile2012. For those of you in the SF Bay Area, I know that Silicon Valley ALN is trying to get them to come and speak later this year.

Review the Slides: Bay ALNhas their slides posted to their Meetup page.

Google it: “Pat Reed Agile Accounting” will find you older examples of the presentation. I don’t know how much it has evolved over the years so this probably is your last option.

Imagine a world where the bean counters were asking the CEOs why the company wasn’t using agile development?


Agile, a Gorilla four letter word

“No, no, no, no. You’re doing it all wrong. For the love of Peet, it’s an easy process to follow.”

Eric shrugged. “Yeah and we found that it wasn’t working with our schedule cycle so we tweaked it.”

I rolled my eyes, “Look, the system works, we just have to trust the system.” I glanced down at my watch. “Look, I have to prep for my next meeting. Can you close the door when you leave.”

Eric blinked, shrugged and walked out of my office. As the door shut I leaned back in my chair with a deep sigh.  It was taking so much work to make the team more efficient. If only they’d just see this was the way to an easier path. Well, at least I’d gotten management to cough up money for training. The entire project had nearly fell face first into the chasm because the CFO had heard productivity increase and rushed us straight towards agile, ignoring all my “people need training” reminders. Our first pilot was nearly our last when nobody had a clue what they were doing.

I rubbed my temples. I’d had to work fast on that one, pulling together a cost benefit analysis to prove that spending money on training would gain us more improvement than going back to the old development model. Leaning back in my chair I stared at the ceiling. Now if I could just get the teams to stop playing around and do things right.

“Why not left?”

I really need to change the lock on that door.

“You don’t have a lock on the door, how can you change it?”

I really need to put in a lock, and then change it. “What do you want, Hogarth?”

“Why does everyone want to do things ‘right’? Couldn’t we try doing it left for once.”

I was about to tell Hogarth that he was making no sense, but then I thought better. Whenever I did, he always made me look like an idiot by then making complete sense. Sigh… “I want to do it the right way, because that’s the way it’s supposed to be done.”

Hogarth sauntered across the room to where a large philodendron sat. Pulling a leaf from the plant, he took a large bite before turning back to me with a sour look on his face. “You know, I much prefer the fichus.” I just gave him a baleful stare. Tucking the half eaten leaf back into the pot he settled down against the wall. “The way it’s supposed to be done,” he repeated.

I just nodded.

“Question, isn’t this release going like gangbusters? Don’t you expect to ship in half the time and with a much higher quality?”

I nodded, a note of pride slipping into my voice. “Yes.”

“Then why are you worried about being right? It’s working, isn’t that the most important thing?”

“But they’re not following the process!” I snapped in frustration. “If they just followed the process, it would be so much better.”

Hogarth scratched the back of his thread as he asked, “Remind me again, the first principle of agile is what?”

I peered at Hogarth in confusion. “Really?” He just gave me a “humor me” shrug and stared at me. Sigh, “all right. The first principle of agile is ‘Individuals and interactions over process and tools.”

“Uh huh… And how are you doing with that?”

Blink, blink… Sigh. I really hate it when he’s does that.
Has Agile become a four letter word?

Worse than that, is it a three letter word? Is agile in danger of becoming the next Management Fad? Nothing is worse than being placed in a bucket with such Fads as “Business Process Reengineering.” You know, the Fad that said if we make the process better, even a bad team will improve?

Shudder…  We don’t want that, do we?

Well guess what? It’s happening. I think this tweet sums it up all to well:

Is it me or are there a lot of people drinking the #agile #scrum kool aid? How bout just focus on being effective? #agile #scrum #pmchat – @tonybruce77

This worry isn’t anything new. Nearly as long as the Agile Manifesto has been around there have been people calling it a Fad. On top of the typical Fad drivers, there are disturbing trends inside of the agile community that are just as harmful.

Here are a three viewpoints.

  1. Poor adoption of agile has driven us into the chasm: Back in Feb, 2011, Agile Focus posted a blog on agile falling in the second chasm. It argues that “there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point.

I tackled this Gorilla back in “Indiana Gorilla and the lost artifacts of agile.” It is certainly an issue, and one that is not unique to agile. If you have $100,000 racecar, but the driver can’t drive a stick, then he might declare the car useless. This point argues that it might just be that you need to train the driver. The inverse also applies. Many companies have “tried” agile, only to mark it as useless because of poor implementation. If you don’t read the manual, you to can end up bumbling around like the Greatest American Hero.

My Soapbox: Agile isn’t a get rich, quick scheme. You can’t toss in a few standups and call it good. It’s a cultural shift. A set of beliefs and ethics that require a company to change more than just how it tests. You don’t do this overnight and you don’t do it without training. To get better, you have to invest in getting better.

  1. That’s not agile! You’re doing it wrong!: Mike, over at Leading   Answers, created the Periodic Table of Agile Adoption.  While Mike posits that, like the real elements, there is no good or bad Agile adoption I’d point out that you really don’t want to get Cesium anywhere near water. And like real elements, there are elements of the agile community that are a little explosive when they perceive you as “watering down” pure agile.  On the Agile Periodic Table, there are some fairly vocal and forceful Ze1s out there and enough Zealots and Fundamentalist pounding on the “That isn’t the way to do it” drum that we are seeing a growing backlash to agile. Not because agile has issues (it does, but that’s not for today), but because these passionate agilists are being perceived as shoving it down people’s throats. Like the fur protestors with their cans of red paint, they go to extremes to make their point. The extremist just might be driving people away.

My Soapbox: I personally come down somewhere in the Te6 or Re6 transformational/revolutionary blending area of the chart. Agile is one of many tools in my toolbelt and I’ll use what works best to help the team, company and myself be successful. Given that I tend to get really upset with those at the Ze1 end of the spectrum. Why? Because one of the first tenants of agile is…

“Inspect and Adapt”

If you don’t change and adjust as you go, then how can you call yourself agile?

  1. Agile isn’t New!: The Agile Manifesto was signed in 2001. In the last ten years, the term agile has exploded across the world and become one of the rising trends that every business is keeping an eye on. Only the concept of agile isn’t ten years old, only the word agile is ten years old. The concepts of agile are a lot older. The first Scrum team dates back to the early nineties. Customer focused development concepts were a major fad in the 1980’s. Lean (which some will fervently  argue isn’t agile, but we won’t go there today) goes all the way back to Toyota’s post WWII reconstruction. And some have given good arguments for the roots of “agile” being in the Hawthorne Study of the 1920’s.

My Soapbox: Agile is a buzz word. In many ways agile is the PMI of its day (Yes, I just went there). Formal Project Management dates back to the 1950’s, but it wasn’t until the late 1990’s that it really began to gain traction. Organizations like PMI (1984) and methodologies like Prince (1989) and Prince2 (1996) brought a measure of formality to a decades old profession.

But the biggest thing PMI (Prince2 in the UK/Europe) did was to give everyone a common language. It took what people had been doing for years, and gave everyone the same words to use for it. Earned Value means the same thing to me, as a project manager in Dubai. It does because of PMI, Prince2 and others who helped to create a language around project management.

The Agile Software Development Manifesto did the same thing for what most of us now think of as agile. Agile is the word we’ve all agreed on to use. Don’t let the word get in the way of long standing and good principles.

So is agile in danger of becoming a Fad?

Yes- And that’s a good thing:

The underlying principles of agile focus on the customer and the team. These are good foundations to have and the popularity of agile has given attention to these foundational principles.

Yes- And that’s a bad thing:

The near fanatical drive that some agilists have, combined with the “get rich, quick” attitude of many companies, who try and implement on the quick, are leading us down a road that could cause a perfectly good set of values to be cast onto the rocks of management faddom, to languish next to jazzercise, Tai bo and the grapefruit diet.

So what would you call it?:

Margaret Motamed, host of the BayScrum Meetuprecently described what she is doing as “Collaborative Management.” A lot of use would insist she’s agile and those Z1s would probably say she was just gaming the system. I think she might be on to something.

Right now I don’t know what I would call it. If I say “agile” you all know what I mean. If I call it “Flexible” then you’re not going to know exactly what I mean.

If I had to describe it in a single sentence:

“I believe in a customer focused, iterative process that is executed through a collaborative effort of the team and company.”

And I have one simple measurement to if I’m being successful.

“Are we doing better this week, than we were last week? If we are, then we win.”

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