Just say “No” to Gorilla Debt in your Teams

By ccPixs.com

Debt Free by ccPixs.xom

You’d think with the amount of time I spend hitting my head on my desk it would have a permanent dent by now.

My most recent forehead abuse was brought short by the one thing I hated more than coaching a team that thought they we’re already perfect. The deep, rumbling bass of my personal gorilla cut through the sound of my head hitting the desk. “The SPFA called, they are filing a restraining order against you for furniture abuse.”

I blinked and looked up at the hulking form of my conscience in physical form. Why couldn’t I have a little cricket like Pinocchio? It would be so much easier to lock him in a jar and toss him in the ocean. “The SPFA?”

Hogarth  nodded, “Yep, the Society for the Prevention of Furniture Abuse. Their motto is ‘Desks Have Feelings Too’.”

“Go away Hogarth, I’m busy.”

Hogarth broke a branch off the nearest office plant and plopped into a chair next to my desk. “Pretty sure, destroy desk with forehead isn’t the most important thing on your backlog. What’s up?”

I sighed, he wasn’t going to go away so I might as well get this all over with. “The team didn’t take into account planned vacations and the product owner used their expected velocity to promise a feature to sales. Half the team was out and the other half was almost totally consumed by blocker bugs.”

Hogarth asked, “Didn’t they have this issue the last three months ago?” 

I nodded.

“And I seem to recall it was raised after the first sprint, over six months ago. Right?”

I nodded again.

“Well,” Hogarth said. “Sounds just like that problem you had with the original login server not being able to scale beyond 1000 simultaneous logins.”

“Don’t be silly, Hogarth”  I snapped. “You know very well we already fixed that issue two sprints ago.”

Hogarth was smiling, I hate it when he smiles like that, it usually means I’m about to be setup. “That’s right, we did didn’t we? How is it we took care of that?”

I didn’t know where he was taking this and I couldn’t just leave it alone, “We identified it as Technical Debt. We put it into the product backlog and worked with the product owner to prioritize it alongside new feature work.”

Hogarth nodded, “So we had  a problem with the product architecture, we recognized it and put it into a backlog with everything else to be prioritized?”

“Yes!” This was starting to get annoying since he was just reviewing what we all knew. Where was he going with this?

“So where is the backlog for the problems with the team? ” Hogarth asked.

Backlog for the team’s problems, like we do for Technical Debt?  Team Debt?

And he’d done it again…

 

Team Debt is just as destructive as Technical Debt

If you have any doubt that we are worried about the effects of Technical Debt, just Google the term. I get just over one million hits when I do. With the concept of agile development now considered in the mainstream, for software development if not all product development, the recognition that we can’t build our way out of technical problems with new features is taking firm hold. While how we approach it may still be an area of wide debate (TDD, BDD, dedicated legacy teams, rip and replace architecture, etc.) we are coming to a fundamental agreement that we need to slow down and deal with the problems we’ve created before we can speed up and build the next wave.

What about our teams though? It can be very easy to forget that agile is not just a new product lifecycle process (PLC). We have been so ingrained that PLC process is about what we are building that we often forget that agile is as much about “who” is building something as “what” we are building.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” –Principle 5  of the Agile Manifesto

Team Debt is the term I use to describe the impediments, issues and blockers that prevent the team from improving. Where testing and product usage will generally uncover your products Technical Debt, it is the Team Retrospectives, manager one-on-ones and coaching observations that will uncover the Team Debt. On the whole, something we are getting pretty good at doing in most agile organizations. Thanks to Scrum, we have built in the concept of the retrospective at the end of every sprint which gives us the mechanism to uncover our impediments.

Of course knowing the problem is only half the battle. We see this with Technical Debt all the time. Sure we know that our infrastructure can’t handle over a 1000 simultaneous logins, or that our core server has legacy code no one even remembers who wrote. We’ve known this for years and we’ve never done anything about it because we were too busy build the next new, wizbang, feature instead.

So just as we need to put Technical Debt into our product backlog and actually prioritize it to be fixed, we need to discover, track and address Team Debt.

The Impediment Backlog

Here, at AOL (Yes, AOL, they  are still around and doing cool stuff in 2016),  I’ve been experimenting with the concept of creating an Impediment Backlog. Just as the product has a backlog of everything we want to do with it, we need a backlog to track the issues impacting the teams. I’ve started coaching my teams to create an impediment backlog and include items from it into their Sprint Planning right alongside items from the Product Backlog. I’m also advocating for the creation of an Organization Impediment Backlog where we track cross and multi-team issues that cannot be solved at the team level.

By making the issues visible and putting them into the same formats as our Product Backlog, we can more easily understand and fit them into our day to day processes. If it looks like a duck, and we’re in the business of making ducks, then it will fit right in. If it looks like a fork and we’re in the business of making ducks then we’re likely to ignore it.

Ask me in a few months how we’re doing, it’s an experiment in the making.

How Agile Coaches are Like Vampires?

Dracula

By Screenshot from “Internet Archive” of the movie Dracula (1958)

For the love of!!!” I bit off my oath before it could move into not safe for work territory. Resisting the urge to slam the door I walked into my office. It had been another banner day in the world of agile coaching and I was ready to collapse into my chair so I could drown my sorrows in Facebook.

 

“Shhhh…. this is the best part”

I did a double take as I realized my chair, heck my entire desk was occupied. With his size gargantuan feet propped up on my desk, Hogarth the Gorilla was watching a video on my monitor screen.

“Hogarth, what the heck are you doing?” Only after speaking did I realize I probably didn’t want to know the answer.

“Watching a movie” he said. His hands were crossed over his chest so only his finger moved when he pointed to the screen and continued, “Bloody revenge of the Nosferatu Clan, awesome 1930’s era flick.” Turning his head towards me ever so slightly he then asked “How’d the coaching go today?”

“Huh, what?” I was thrown by his sudden change of conversation and quickly forgot all about his misuse of my computer as I recalled my day. Tossing myself into the guest chair I sighed, “Lousy, absolutely lousy.” I started ticking off my fingers. “One of the teams is in a tailspin after a disastrous planning meeting, to which I was not invited.” I ticked my second finger, “Another team can’t get anything done in a sprint and seems to think they don’t need to do retrospectives they just need to work harder, and they won’t listen to any of my advice.” I ticked a third finger, “I held a story splitting workshop for the scrum masters and product owners, only no one showed up. Too busy they say.” I started to raise a fourth finger when Hogarth raised a hand to stop me.

You know?,” Hogarth began. I knew this lead in. His next words were going to be some brilliant epiphany that even though I’d want to deny it, he’ d be right. I just sipped my coffee, waiting for the gorilla to drop.

“Agile coaches are really a lot like vampires.”

“What?” I spluttered coffee across the desk in my shock. There was no way this was some brilliant epiphany. Hogarth had finally cracked. “How on earth is my job like that of a blood sucking soulless demon? I am not an attorney!”

Hogarth waved to the monitor screen. On it the vampire was thrashing about in an open doorway unable to reach his intended victim who was only just inside the door. “Vampires have to be invited in.”

Invited in? Hogarth was relating me to an evil creature of the night and how it couldn’t cross the threshold of your home if you didn’t invite it. As long as you didn’t invite it, it was powerless to do anything.

Oh…

And once again, Hogarth had hit the crux of the issue.

 

How are Agile Coaches like Vampires?

  1. We have to be invited in.
  2. Our greatest power lies in influence.
  3. We need blood to survive.
  4. A stake through the heart destroys us.

We have to be invited in: Fans of 90’s era Buffy the Vampire Slayer will know this one very well. Vampires can’t cross the threshold of your home without your permission. So long as you don’t invite them in, they are stuck outside throwing taunts and jeers at you.

Whether you’re consulting or a full-time coach, if you don’t have an invitation you are not going to be effective. Something you learn in life coaching is that success requires something akin to a ‘rules of engagement’ with your client. You can’t just show up and start telling them what to do.  If your coaching client doesn’t want your help, or doesn’t want it in a certain way, no amount of talking or prodding is going to make you successful.

It’s the same thing for agile coaching. Even if the CEO personally hires you, and anoints you as the holy expert of agile, if you don’t get buy in from the teams, you won’t be effective at all. You can’t force yourself on the teams, you have to make yourself valuable to them. Start by asking questions, gathering feedback and observing what is happening with the teams. The act of doing this will help to build trust with your teams. You won’t be able to do anything without that trust.

Our greatest power lies in influence:  If you ever watched the 1990’s Dracula, with Gary Oldman and Keanu Reeves (You can be forgiven if you didn’t ), there was a big emphasis put on this aspect of a vampire’s power. And no wonder they have these power, when sunlight kills you, holy objects burn you and common garden herbs make you recoil, it’s hard to use the direct approach to get to your victims. So vampires use their mental powers to lure their victims into their deadly embrace.

Like the vampire, the agile coach can’t bull their way through a transformation. In order to be effective, they need to use personality and influence. We’re talking about “soft skills” here. You know, those things that have been made fun of for the last three decades, only suddenly now people are realizing they really matter (thanks to influencers like Sinek, Pink and Gladwell). The agile coach has needs to ask what the team think instead of trying to tell them. You have to let the team find the answer, not push it in their face.

We need blood to survive:  Okay, bit of a stretch so stay with me. Vampires need life force to survive. They get this through the blood of their victims.

Agile Coaches need energy as well, the energy of interaction. If we are locked away in a tower, with no interaction, we are not effective, we will fade away. If a motor is not used, it will stop working.  Having really smart coaches sitting in some central office, writing blogs, giving remote advice and the like is a waste of good assets and won’t make your teams better.

A stake through the heart destroys us:  Well, yeah wouldn’t a stake through the heart kill you too?

So yes, Agile Coaches are a lot like vampires. We need to look to be invited, we need to build trust with the teams, we need to be a light in the dark and we need to wear sunscreen outside.

Have you invited your agile coach in lately?

The Gorilla asks: “To FTE or not FTE? That is the question.”

Or why I choose to be a full-time coach.Monkey-Yorick

“Explain to me again why we’re going to be renaming projects ‘missions’ and our teams are now ‘squadrons’?”

My boss waved his hand vaguely, “It’s the new consultants we brought in. Bunch awesome hot-shots. Their workshop was totally eye opening. I mean the military has been running fast projects for decades. Why didn’t we think of it sooner?”

‘Because we’re a data processing company with absolutely zero to do with the military’, I thought.

“Anyway,” he continued, “I think we should roll their recommendations out. You’re the coach, what do you think?”

What did I think? I tried to fathom the depths of his question and failing that I went with the obvious. “Well it’s hard for me to say. I didn’t go to the training so all I have is this promotional flyer you just handed me.”

My boss nodded gravely. “Yeah, that was unfortunate. But you’re a contractor so the company can’t send you to training.” He clapped his hands on the desk, and pushed himself to his feet. “Tell you what, spend some time Googling it and give me an assessment tomorrow. I’ve got to get to the strategy planning meeting.”

I started to open my mouth only to have my boss wave me to silence. “I know, I know. It would be so much easier if you could be in the meeting. Confidential company data and all though. I’ll brief you on what you need to know tomorrow.”

And with that he was gone, leaving me in his office staring at the flyer of some consultant, who I didn’t get to talk to, that I was supposed to give my opinion on how to implement. I buried my head in my hands and contemplated becoming a beat farmer.

“Hey,” the voice was deep and earthy “was that your boss I just saw walk into a conference room with those Fly Right Consultants?”

Oh my day couldn’t get any worse. Not only was my own personal gorilla here to torment me, he was telling me even the consultants get to go to the meeting I should be running. “Go away Hogarth, I’m not in the mood.” 

“Yeah well how do you think I feel. You try explaining to the security rhino why you need a security pass when you’re just the figment of a contractor’s imagination. You’d think a fellow hourly guy would have some sympathy for my plight.”

I hadn’t sufficiently tuned out Hogarth and what he said pierced into my brain, jumping me into action. “Holy …., I forgot to put in my time card!” I started to jump from my chair only to be stopped by Hogarth’s massive hand in front of my face.

“Don’t worry, I turned it in for you this morning?”

I blinked. “This morning! It’s 6:00 pm how can you know how many hours I worked today?”

Hogarth gave a dismissive shrug. “It’s not like that matters, you know they’ll only pay you for forty hours no matter how many you actually work.”

Not for the first time I came to the conclusion that being a contractor sucks.

 

Agile Contractor, Agile Consultant, Agile Coach, the continuum

There are several paths to becoming an agile coach (leader, champion, guru, insert your adjective of choice).  The most common path starts first with being a scrum master and then moving up into being an agile coach. A less common path is doing program management in an agile organization and moving from there into agile coaching.

What about once you are an agile coach? What then? How will you collect your paycheck? What is your place in the organization? As I see it, there are three paths one can take as an agile coach. Coach, Consultant, Contractor. Let’s review how these work, their pros and cons.

Full Time Agile Coach: A full time coach is perhaps the rarest form of agile employee you will find today (2016). While full-time scrum masters are not uncommon, the coach is more often a consultant or contractor with a sharply limited engagement. And I see this as a tragedy. The full-time coach is perhaps the most effective and cost-efficient solution a company will find.  Sure, being a full-time coach does not offer the short-term satisfaction that consulting does. What it does offer is stability, trust and the ability to make real changes.

Benefits of being a Full-Time Coach: Longevity and trust. As a full-time coach you are not under the tight time windows so often imposed on consultants. And being full-time means you have the time and position to build trust with your teams, manager and company. In a good company (life’s to short not to work for good companies) you have the time to get to know your teams and build up relationships and trust before you start getting into the deep work of agile coaching.

Downsides of being a Full-Time Coach:  You’re in the system. When you are inside of a company, reporting into the management structure and working within the politics, you lose a certain amount of authority and power. You can’t call on the “hero for hire” aura to push through your ideas. You may know the exact right thing that needs to be done. That’s great, now you have to convince  your management. It can be a frustratingly teeth gnashing feeling to know and not be able to do. You also have to get used to change moving slower. Your company isn’t losing you at the end of the contract and working hard to push everything through.

Consultant Agile Coach: As a consultant you can feel like one of the Magnificent Seven (either the Samurai or  Western version). You are hired for your specific expertise and when you come into an organization your word carries a voice of authority that can sway the course of CEOs much less the rank and file employee. You need to speak that authority fast though and you need to make it stick because you won’t be around for long.

Benefits to being an Agile Consultant: The “Expert” aura. Companies pay good money to hire consultants. Something about investing lot’s of money in you means you’re listened to; given access to people, meetings, and information; even given a certain amount of authority to make changes.  It’s a really big advantage. It is however pretty much your only advantage.  Yes, it is common for consultants to know a lot and have a deeper set of experiences than your average Full-Time or Contract Coach. This is not a benefit though, it’s just a recognition that currently the consultant space draws a high percentage of the top tier coaches. The other advantage of being a consultant is shared with contractors, that being “control of destiny”. A consultant, particularly the independent consultant, gets to pick and choose their clients and can choose to work or not work. A full time coach doesn’t get to say “I don’t like this team, I’m not working with them.” A consultant can do this (though if they do it too often they find their phone stops ringing).

Downside of being an Agile Consultant: The agile consultants are heroes, therefore they are expected to work miracles. The miracle they are usually expected to work is to make a difference in a vanishingly short time window. Ninety days in not an uncommon duration for a consulting engagement. Ninety days is a brutally short time window to get anything done in. In, The Ninety Day Gorilla, I talk about how a full time employee should practice the mantra “Do no harm” in their first ninety days. For a consultant the money often runs out by the time ninety days are up and if they haven’t made some kind of impact, they won’t be asked to come back again. Worse yet, the client will talk to their friends and those friends are no longer potential clients. If you can’t hit the ground running, cure world hunger, make the client happy, all in three months, consulting may not be for you.

Consultants also come in two major flavors, Independent and “Firm”.

The independent contractor is the ultimate in self-determination. They hang out their shingle on the power of their name alone. You hire that one person and bring them in for their expertise. If you’re lucky and wildly successful (Jeff Sutherland, Joe Justice, Mike Cohn) you can afford a staff to help you. Otherwise you are coach, bizdev, bookkeeper, scheduler and receptionist all in one.  You’re also always chasing the next paycheck. Even while helping profitable client A, you’re actively working to land client B, D and C.

“Firm” consultants work for a larger organization. In agile some of the big names are SolutionsIQ, Leading Agile, and Thoughtworks). Agency consultants have some more security than the independent and much more than the contractor. If you’re good, the firm will take care of you. You will probably get benefits, bonuses and a certain amount of immunity from the “what’s my next gig?” panic. You might even end up on “bench time” where you are being paid to do mostly nothing (write training, blogs, help with BizDev).

Contractor Agile Coach: Where as the Consultant is hired “hero”, a contractor can often feel like they were picked up at the local “Henchmens ‘r Us” outlet. A contractor is hired as an hourly employee that works within a company’s normal organizational structure. They are contracted through an outside agency who issues their paycheck and benefits (if applicable). They report to a manager within the company they are contracted to. Thanks to past legal cases, contracts are always for a fixed term so as to not ever imply the contractor is an actual employee. Depending on the company the max term usually ranges from twelve months to two years. Since this is not a fixed law, smaller companies tend to pay less attention to this and I’ve seen five plus year contractors at post startup, pre-IPO companies.

Benefits to being an Agile Coach Contractor: Honestly, not a lot. Like an independent consultant, the greatest benefit is you are in total control of your destiny. You interview with a “client” on your own merits. You decide when to work and when not to work. The advantage over independent consultant is that the contracting agency handles all the pesky paperwork for getting paid, benefits and the like. If you’re not ready to hang out your own shingle and don’t want to work for an established consulting firm, this is the greatest path of independence you can find.

Downside of being an Agile Coach Contractor: You’re getting the short end of the FTE and Consultant sticks. Contractors are considered “Staff Augmentation”, so they are treated as part of the organization they work for. They report to a company employee and are almost always the “junior” person in any department. Staff Augmentation means you don’t have the aura of being a hired “expert”.

And as a contractor you have the same fixed time window of a consultant. Last year I interviewed with one of the old enterprise players in Silicon Valley (you know the companies that were the big guns until Google and Facebook came along and Apple started their “i” wave of products). They were trying to engineer an end-to-end agile transformation of a core business unit. Only they were looking to hire an agile coach on a three month contract and expecting significant results in that three months.

So without the mantle of “expert” given to a consultant, a contractor has a doubly hard time being successful in the short time window given. That company I interviewed with last year is on something like their seventh agile coach contractor and no closer to real change than they were two years ago.
So… (Conclusion)

I’ve worked as a contractor, a consultant and a full time employee. While few would support contractor as the preferred way to earn a paycheck, the “Consultant or Full-Time” question is common.

For me the answer has become clear. I find it much more fulfilling to be a full-time coach. I’m not saying I won’t consult again in the future. What I am saying is that being a full-time coach I believe is the best combination of pros and cons of all the options.

Of course an even bigger question is what should companies hire?

You’ll have to wait until the next blog for that answer.

This blogs is a prequel to my upcoming Agile Coaches Playbook series. This blog is specifically inspired by my session at Agile Open Northern California on Oct 9 and 10. Special thanks to Mike Register, Sam Lipson, Ravi Tadlwaker, Arielle Mali, Eric Johnson, and Gautam Ramamurthy for their great contributions.

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

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

A Gorilla is more than the sum of its parts. So is Agile.

Car_Exploded _View_David_Wall_6999872214_93978664bc_z“Agile is failing, can you believe that, he actually said that to me?” 

You know you’re having a bad day when you willingly engage in a conversation with an 800 pound imaginary gorilla. I was striding down the hallway fairly vibrating with emotions. Hogarth lumbered along beside me uncharacteristically quiet. Which I guess should have been my first clue as to the rabbit hole I was being led down. 

“How can he say that?” I looked directly at Hogarth, “I mean we’re doing standups every day now. I even got them down to 30 minutes.” 

Hogarth finally chose to speak immediately making me wish he hadn’t, “What about the backlog?”

I threw my hands up “What about it? The backlog is being pulled straight from the PRD and we got the product manager to rank order them instead of the stupid P0 stuff. I mean how much more agile do you want us to get?”

Hogarth nodded sagely, or so I thought and I turned to walk into my office. Where I promptly stopped. 

“Hogarth, where’s my fichus?” The pot that held my latest incarnation of my favorite fichus was empty. Not just denuded of leaves and branches, empty. Even the dirt was gone. 

“Oh, that” Hogarth said. “Sorry, about that. I did replace it though. Here.” 

Hogarth reached under my conference table and started laying several objects on the table. A sack of dirt, a trunk, several loose branches and a sack of leaves. 

“Hogarth…. What’s that?” 

Hogarth smiled cheerfully at me. “Oh that’s your new Fichus. Well at least it’s all the parts to a fichus, you just need to put it together.” 

“HOGARTH!” I put up with a lot from my imaginary gorilla. His eating my plants wasn’t the end of the world, they made for a nice tax deduction. But this… This was going too far. “Do you think I’m some kind of Dr. Frankenstein? I can slap this all together with some glue, yell ‘IT’S ALIVE’ and suddenly I’ll have a fichus?”

I stared at Hogarth, my eyes blazing with a demand for an answer. 

Only no answer was forthcoming. Hogarth and retreated to the corner of the office and was sitting in his ‘happy budda’ pose with his hands clasped happily over his hairy belly. He just kept staring at me, as if he’d already answered me and was waiting for that inevitable moment when all the pieces would crash together making whole the monumental idiocy I’d…. 

Pieces… Made whole… Sigh…

Putting my head in my hands I said “and we’re so focused on doing the artifacts of agile we’re completely missing the spirit and purpose which would make it whole and successful ?” 

“Pretty much,” said Hogarth. 

 

A pile of parts does not Agile make

“We’re doing stand ups, we must be agile.” Admit it, how many times have you heard this? Honestly it’s grown to internet meme status and is one of the go too jokes for mocking a company that has failed to “get agile.”

That doesn’t mean it isn’t hitting the truth smack dab on the head.

Yes, the practices of agile are incredibly important. So is structuring your organization with interactive support from all tiers of the company. If you only do the motions though, you’ll end up with an organization that is a soulless automaton not unlike Frankenstein’s monster. The monster was “alive”, but lacked a purpose and drive, a soul if you will. It at least had the intelligence to know it lacked something and spent the story trying to find acceptance and love.

In some organizations they are just like the monster, in that they know what is missing, but their efforts to find the missing is stymied. This can be the teams own roadblocks or barriers imposed by the company or even external partners and customers. These organizations are almost sadder than those oblivious to what’s missing in their agile transformations. They know they are not getting what they should out of agile while being forced to go through the motions of agile every day.

The same cannot be said for all attempts at agile transformations. They muddle along doing the practice of agile, without the purpose of agile and they either gain minimal benefit from agile or fail completely. Often blaming agile they then fall back on whatever they were doing before because it has the comfort of familiarity. These organizations then face an even greater challenge in improving because “we tried it already and it didn’t work.”

An agile transformation is more than just predictability, stability, shipping early, or even transparency. Agile is a tool that can lead an organization from being extrinsically driven to intrinsically driven. From unengaged to fully engaged. From passive process following to active innovation creation. In short all those things we are hearing about from such modern luminaries as Steven Denning, Dan Pink, Eric Ries and past visionaries such as Peter Drucker, are things that an agile transformation can help with.

If you truly set out to do it and not just pick up a couple of pieces and expect to be able to have the value of the whole.

 

Gorillas use the 5 Whats not the 5 Whys

“Can someone tell me why I just spent two hours on the phone with a screaming client?”

“They dropped a server rack on their toe and it really hurt?” asked Greg.

I glared at Greg until he went back to studying the dirt under his finger nails. The I turned to Jake, our development manager. “Jake, why can the client only load half their user base into the DB?”

Jake gave a shrug. “No clue, why didn’t QA test that?”

Vinnie jumped forward in his seat, “That’s not even in our test cases, why on earth would we test that.”

The room seemed to pause for a moment and then all eyes slowly turned towards to Tully, our junior product manager. With Bob visiting a potential customer, Tully the product management representative.

An hour later I walked into my office, tossing my coat on the conference table chair. “Poor Tully” I muttered.

“Why?”

I jumped. Turning to look where my coat landed I saw instead Hogarth holding my coat in one hand and looking at me with a questioning gaze.

“Why? Because Tully got torn to pieces in that meeting.” I said.

“Why?”

I blinked at my Gorilla. It wasn’t like him to not know everything. After all wasn’t he just a figment of my imagination? “Because Bob wasn’t there. And Bob is the one who made the requirements that didn’t address the customer’s number one need.”

“Why?”

Now I glared at my gorilla, was there a point to all of this? “So do you have a point with the annoying string of ‘why’?”

Hogarth nodded, “I do. What do you think would be a better way?”

“What?” My brain started spinning, how was this an answer? What did he mean? What was the right answer? Wait, wait, What?

And Hogarth nodded, “Exactly.”

 

Why the 5 Whys should be the 5 Whats.

Unless you’ve been living under a rock, you’ve almost certainly heard of Sakichi Toyoda, the founder of Toyota. He calls it Five Whys. Unless the rock was really heavy, you’ve also no doubt heard Simon Senek’s “Start with Why” TED Talk.

The Five Whys:

5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships of a problem. The goal is to get to the root cause of a problem, because all too often the first cause is not the true cause. Doctor’s call this “treating the symptoms, not the disease.”

An example the 5 Whys :

Why did our service go down?

  1. Why? – The servers lost power. (first why)
  2. Why? – The backup power supply didn’t work. (second why)
  3. Why? – It couldn’t handle the load. (third why)
  4. Why? – A replacement hasn’t been bought that can meet the power needs. (fourth why)
  5. Why? – The DataCenter budget was frozen last quarter and we haven’t had the money to perform upgrades. (fifth why, a root cause)

Starting with Why 

Simon’s talk is an incredible exploration of how companies can be inspirational and change the world. His Golden Circle places the question “Why” directly in the middle of the circle and What is placed at the edge. As Sinek pounds home, “People don’t buy what you do, they buy how you do it”

The danger of “Why”

“Start with why” is an excellent for a company exploring how they can better market their products. It can help them to better connect with their end customers and provide greater value.

And “why” is completely the wrong word to use when trying to get to the root of a problem.

What makes me say that? Professional coaching has a key concept of using powerful questions. These questions are deigned to help the coach guide the coachee to the answers they need. The coach doesn’t give the answers, the coach doesn’t even guide the answer. The coaches job is to ask the powerful questions that will allow their client to get to the solution. Examples of powerful questions are:

  • What is important about that?
  • What is stopping you?
  • What is the lesson from that?

What you won’t find in powerful questions is “Why”. What is the reason for this?

“Why” questions rests on the popular belief that « to succeed, one should understand how one has failed ». In other words, to learn how to swim, one must carefully analyze how one has almost drowned. In effect, why questions only let clients meander within their same-old limited past frame of reference. A good coaching process needs to gently lead the client out of their box.” (quoted from www.metasysteme-coaching.eu)

The question “why” carries a lot more emotional content than it’s cousin “what”. When you ask someone “Why didn’t you take out the trash” you are essentially putting them on the defensive and laying blame. Even saying “why is the trash still here?” creates an adversarial space.

This is “Why” is not used in coaching. You don’t want the client to get defensive, or wrapped up in the “why” of the problem you want to ask them “what” they need to do to get out of the problem.

Why 5 What’s is better

You see, Toyoda’s 5 Whys could get to the root cause, but all too often I find they side tracked by the personal agendas, defensiveness and the tragic corporate blame game circle. The 5 Whys can so easily go wrong, let’s look at the example above again, this time with real people involved.

Why did our service go down?

  1. Why? – Because we lost power. (umm duh)
  2. Why? – Bob hasn’t replaced the damn UPS yet, I’ve been on him for weeks. (the buck is passed)
  3. Why? – Don’t look at me, I’ve been trying to get the UPS replaced for weeks, finance won’t approve the PO. (the buck passes again)
  4. Why? – Unless sales starts signing up more customers, we won’t be approving a lot more POs. We’re broke.

We didn’t even get to the 5th why at this point and totally missed that the UPS isn’t broken, just can’t handle the load, so you can’t even explore how to make what you have now work for you.

Let’s try with What.

What caused the service to go down?

  1. What? – We lost power to the core servers and the UPS didn’t work
  2. What happened to our UPS- It can’t handle the load we have.
  3. What are we doing about it?- Well we’re trying to get a new one, only budgets are frozen right now.
  4. What else could we do? We could try putting just half the servers on the UPS. If we lost power we wouldn’t be able to handle a full login load, but we’d be partially up at least.
  5. What do we need to start doing that? – Give us the okay and we’ll have it done tonight.

Asking “What” is about creates an environment of clearer answers. If you ask “What is the speed of light” you get a very specific answer of 299 792 458 m / s. If you ask “why do people fight?” you could fill a Google datacenter with the results. Not a fair comparison? You’re right, it’s not. “Why” is used when the answer isn’t as clear or there are more than one answer.

So let’s try and experiment. What would happen if we used the 5 Whats instead of the 5 Whys?

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

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

 

 

Reviews: There is no "Gorilla" in "Team"

“That’s it! Kill me now!” Throwing myself into one of my office’s guest chairs I directed an exasperated look at Hogarth.

 

Sitting in the corner, fichus on one side, bamboo on the other, he looked at me with placid eyes. Not say a word to me, my gorilla chewed slowly on a head of lettuce.

 

Trying to not think about where he got a head of lettuce I gave a deep sigh and waited.

 

Hogarth kept chewing.

 

I threw my hands in the air, “I mean it! Just put an arrow right through my heart. It’s just not worth the trouble of trying to go on.”

 

Hogarth set the lettuce down. Good, now maybe he’d say something outlandish so I could get angry and him and distract myself from my misery. Looking at me for several long seconds, he then picked up the remains of a fichus branch. Beginning to pick his teeth with the denuded branch he continued to stare at me mutely.

 

“Oh, fine! I see how it is,” I snapped. “When I don’t want your pithy words of wisdom I can’t get you to shut up. But when I actually want your help you just sit there and remain mute?”

 

Hogarth shrugged. “Well I’m a poor archer and I’d really rather not get blood on my fur, so I’m not going to kill you. Lacking any other information, I have a leaf stuck between my molars.”

 

“Argh!” He was so infuriating. Couldn’t he be a normal and reasonable human being? Right… 800 pound imaginary gorilla. What was I thinking? Sigh, I hate it when he’s right.

 

“We’re headed up on year end.” Hogarth nodded in agreement. “That means annual reviews.” He nodded again. “And it means my agile teams have just become a pack a ravening piranha out to be last fish standing.”

 

Hogarth cocked his head to the side, “Fish don’t stand and isn’t the whole point of an agile team that they all pull together?”

 

I jumped up and pointed a finger at him, “Precisely!” Realizing pointing at a gorilla was probably not smart, I lowered my arm and continued. “That’s the whole problem. The review process measures individual goals. Suddenly all my agile team members are scrambling to show how good they are and fighting for credit of who improved the database, or made the UI fixes, or identified the root cause of the uRay issue.” I waved towards my office door, “productivity has plummeted, morale is holed and I’ve even had to break up a couple of yelling matches.”

 

Hogarth shrugged, “Sounds like the review process is broken.”

 

“Give that gorillas a cigar!” I exclaimed. “Only it’s not really broken, it’s just the way it is. Yet another process that doesn’t match with agile. I’m doomed. Agile will never work outside of small startups.”

 

Hogarth shook his head, “No, it’s broken. You don’t measure your spaghetti one noodle at a time.” I stared at him in abject confusion. Seeing this, he said,  “when the four man bobsled crosses the finish line fastest, who wins?”

 

“The sled team of course. What’s that got to do with this? They are all in the same sled.”

 

Hogarth nodded, “Good point.” Hah, I had him now. “What about the four hundred meter freestyle swimming relay? Michael Phelps carries the whole team, everyone knows that they couldn’t win without him. Why give the medal to anyone else?”

 

“Hogarth that’s silly. He couldn’t win without them.  It’s not like he could have swum all 400 meters himself.”

 

Hogarth nodded again. “Yes, that’s right. There is no ‘I’ in team.”

 

“I know that!” I snapped. “We’re doing agile after all. It’s all about the team. Team empowerment, team accountability, team rooms, we even have team plush toys for Ghu’s sake!”

 

“Then why are you measuring individuals and not the team?” Hogarth asked.

 

Huh… Why indeed?

 

 

Agile Reviews for Agile Teams

 

The average corporate review process is an almost myopic focus on the individual. What have you done? What goals did you achieve? What milestones did you meet? You, you, you. Almost like a bad country western song. Everything is focused on the individual worker and what they did. You don’t get credit for being part of a successful launch team. No, you only get credit if you led the team, or did some great thing ,that no one else did, to save the launch.

 

And that’s the good companies. There are companies out there (I hear Microsoft is a big sinner here) that use stack ranking. If you have a five person team, you can only give one person a five star rating and by the same extension, you have to give someone a one star rating. How do you think your team is going to behave when their literally is no points for second best?

 

Traditional review styles are murder on normal teams. Just imagine how much worse they are on an agile team? Agile teams promote the team owning the deliverables. The team does the work. The team commits. The team delivers. Until review time, and then hold on tight because it’s every developer for themselves.

 

It doesn’t work. You’re killing your teams one review at a time.

 

We don’t have a choice, it’s the way HR does reviews.

 

First of all, go read last weeks blog. If one junior captain can change the US Navy, then a manager can certainly change how his team is measured.

 

As for how to do it, well that I can’t take credit. I learned of this from an agile training house here in Silicon Valley. Agile Learning Labs has factored into my own agile journey many times. The founder, Chris Sims, is one of the people who took it as a challenge when I said “You’ll pry waterfall from my cold, dead hands” (Oh yes, I did say this, once upon a time). I took my CSM course from ALL and learned about the real value of agile for the first time, while getting the straight talk on how effective a CSM is (not much, you should still get one, from a good teacher, it’s a great way to learn).

 

Agile Learning Labs was asked to help a company that was facing just the issues we’ve discussed. The company had gone completely agile and was very happy with the change. Unfortunately, when it came time for reviews, they experienced significant disruption across the company for the entire review cycle. I’m guessing for a time after the cycle ended as well, as people digested their reviews.

 

So ALL worked with the company and implemented a new review process. No fancy math, no weird hoops or process and absolutely no touchy feeling trust falls.

 

Each employee had their review divided into two equal parts.

 

The first 50% rated them on how they met their individual goals. These were goals created with their manager (Oh, hey how about the Manager Tools Coaching Model) and focused 100% on things that were only about that employee and their development as an employee. Things like “Will become proficient in Ruby,” “Will present to an audience of at least 50 people,” “Will be on time to work 95% of the time” (Sometimes your goals are not big and earth shattering). Most importantly is none of this 50% had anything to do with their work on the team.

 

The second 50% was how well their team did. The team was measured on how it succeeded in its  business objectives (shipped the product, fixed the defects, shortened the release cycle by 25%, etc.). And then every single person on the team was given the exact same rating. The exact same! If the team did poorly, then everyone might get 20%. If the team was a rockstar band, then 50% all around.

 

That’s not fair! One of our team is a total slacker!

 

Then even money says you don’t really have an agile team. Still, let’s give the benefit of the doubt here, shall we? If one of the team is not performing, then it’s the team’s responsibility to deal with the issue.

 

Let’s head back to the Olympics, shall we? The swim team analogy probably isn’t the greatest. The relay is based on who is fastest on the Olympic team. These guys are rivals most of the time and don’t train together except at the Olympics.

 

Let’s look at the sculling team (that’s rowing, people). A four man sculling team trains together year round. They are a true team in every sense. If one of the team is not performing, do the Olympic judges say “Hey, you’re a horrible team mate, out of the boat”?

 

No, they don’t. That team mate never makes it to the Olympics. The team takes care of it. Sure, they may have help from their coach (Coach, hmm. Could that be a manager?). The team takes care of the problem and they make it to the Olympics.

 

If it works for an Olympics sports team, it can work for a software development team (or hardware, or marketing, or…).

 

Let’s go back to Agile Learning Labs and the company they were helping. A year later, the company went through the first full review cycle. They’d been using the new model all year and everyone knew this was the model and got reminded through out the year. What happened? It worked. It worked great. The details that ALL has shared is that morale went up, productivity went up and teams didn’t miss any strides during review time.

 

Want to know more? I hear Agile Learning Labs is available for hire.

 

 

So take the “I” out of the team and start measuring the team, as a team.

The Gorilla argues, rework is faster

“What do you mean you’re throwing the prototype away?”

 

Wally nodded, “Yeah, we’re done with it. Time to start on the production design.”

 

“Are you crazy?” I squeaked. “We’re a month behind schedule and you’re going to start over? Has everyone lost their senses around here?” I pointed at the prototype, sitting on my desk. “You’ve got a working model right there. You take it back to your mad scientist lab and you make that work. Sales set up a big demo with a customer next week.”

 

I watched Wally sulk out of my office, the prototype clutched in his sweaty hands. “Seriously,” I said to the ceiling, “what part of move fast doesn’t anyone understand? Rework the whole hardware design from scratch? What next, we’re going to rearchitect the database.”
 

“Probably wouldn’t be a bad idea,” a deep voice said. “It was built seven years ago for a product that didn’t have half the technology we do today.”

 

“Go away Hogarth,” I said without looking down from my ceiling tiles. Staring at acoustical tile can be so relaxing. Especially when the alternative is to talk to the gorilla in the room.

 

I could hear him shuffling across the floor (do gorillas generate static electricity when they shuffle?). “Seriously, old Wally has the right idea, you know that?”

 

I dropped my eyes to give Hogarth a baleful stare. “Right…. And I’ve got some great property to sell you on the moon.”

 

Hogarth shrugged, “hasn’t been a primate on a space mission since the 70’s. Wally is just trying to build a better product.”

 

I waved my hand dismissively. “Maybe, but if its late it won’t matter how good it is. He’d be redoing a ton of work if he tossed out the prototype.”

 

Hogarth nodded, “and by starting over, he could make the unit more efficient, more stable and more reliable. With the prototype he’s got to work around the initial mistakes. Kind of like using suction cups to put a luggage rack on a car instead of having rails built into the car to start with. It will never be the same.”

 

“Hogarth…” I was getting annoyed with his argument. I had real work to do.

 

He dropped into the chair across from me, “Or how about house painting?” My total confusion at his non- sequitur gave him a chance to continue. “To do it right, you paint more than one coat. If you try and paint just one, really thick coat, it ends up not working and will start pealing before too long.”

 

“Why are you hear anyway?” I snapped. “If you’re here to pester me about the prototype, forget it. It works and we just need to tweak it to make it ready to ship.”

 

“Oh, right,” Hogarth said. He laid a sheaf of papers on my desk. I don’t know where he produced them from and I’m pretty certain I didn’t want to know. “I’ve been writing book and I wanted you to look at it.” He held up a massive hand, “Sorry, it’s in long hand. You ever tried to use a human keyboard with fingers this big?”

 

“A book?”

 

Hogarth nodded, “Yep, ‘Conversations With The Gorilla In the Room.

 

I took the stack of papers from him and started to look them over. My eyes were instantly assaulted by a riot of writing. The regular paragraph structure was all but invisible underneath a multitude of struck out words, overwritten corrections, whole sentences inserted in the margins, and lines moving words, sentences and even a whole paragraph around the page. I never made it past the first page.

 

Looking up from the papers I looked across a Hogarth. His face was eagerly looking at me for reaction (note- Gorilla eager looks a lot like “I’m going to eat you”). “Hogarth, this is a mess, I can’t read it.” I held the page in front of him and pointed to the first paragraph. “You’ve got two sentences crossed out and three new ones hand written in. We won’t even go into the grammar issues you’ve introduced into this.”

 

Hogarth looked at the paper, “Yeah, well I really didn’t want to write it all over again. You can still read it, right?”

 

I boggled at him for a moment. “Well, yes, I can follow it. But that’s not the point. It’s like you took spit and bailing wire to your writing. It’s haphazard and inconsistent. I’ve bloody got to turn the page sideways to read this added stuff.”

 

“Rewriting it would have taken too much time though,” protested Hogarth.

 

“Hogarth,” I slipped into my professor voice. “Rewriting is part of the process. Not only does it make your work better, it makes it easier for others to follow it.”

 

Hogarth’s eye lit up, “Oh you mean it will work better? Kind of like the carpentry maxim of ‘Measure twice, cut once’?”

 

All but standing up in my chair, I replied, “Yes, precisely!…” And then I stopped dead. Looking Hogarth straight in the eyes I said “You did it to me again, didn’t you?”

 

Hogarth pulled a fichus branch from somewhere and began to merrily nibble at it. “Uh huh, I did.”

 

Hoisted on my own gorilla, again.

 

 

REWORK, REFACTOR, REDO: GO FAST TO GO EVEN FASTER.

 

“Go slow to go fast.” I’ve heard that motto since I first got into project management.

 

Agile and Lean development practices recommend the use of rapid prototyping. In essence, build something, see how it works and then build it again, even better the next time. This is more like “Go fast, to go even faster.”

 

It’s no wonder then, that Big Design Up Front (Waterfall) schools of development rail against this concept. They don’t see this as incremental improvements. In their mindset it is like tossing out the baby with the bath water. You’ve got a perfectly working “product” (software, hardware, lifecycle, whatever), so why start over? This is even more insane than going into existing code and “cleaning it up.” At least with refactoring existing code you aren’t tossing out the original work.

 

One of traditional project managements all time favorite fables is the “Tortoise and the Hare.” We love to quote this fable. We also love the old maxim of “eight hours of planning will save eight weeks of work.” Even years into my Agile/Lean journey I  have trouble letting go of this fable.

 

Only this concept isn’t as full proof as I once thought it was. If you spend a year planning without any doing , you’ve got a year farther from being done and a year farther from when you validated (we hope) your requirements with your customer. In his book, The Lean Startup, Eric Ries successfully shows that rapid prototyping can be successful. He demonstrates how doing this can allow you to succeed even when the final product looks nothing like what you started with.

 

Yes planning is important. Planning though is not the plan. Planning is communication. Planning is making sure everyone is on board and moving in the same direction.  Only planning without doing is like trying to teach dancing by talking over the phone. If you can’t see what you’ve built, you can’t know if your plans are any good.

 

Like Hogarth and carpenters for centuries have said. “Measure twice, cut once.”

 

Let me modify that.

 

“Build twice, ship once.”

 

 

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?

“Hogarth!?!”

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?

AGILE SUCCESS? FOLLOW THE MONEY….

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?

Imagine…