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…

Does a Gorilla by any other name still smell?

Or- What’s my title? 

I stared at the words. And all I felt was a complete and total lack of enthusiasm threatening to overwhelm my very being.

–  Project Management Professional  –

How… dead. I just didn’t have any feeling for the words. Words that described a good portion of my professional career. Words that had gotten me where I was, only to leave me feeling flat and listless. I sighed. “Oh well, it’s not like the words make the man.”

I moved my mouse over the “Ok” button and prepared to commit to another 1000 business cards. One thousand cards that described me about as well as calling the Bugatti Veyron Super “just another car.”

“Why don’t you just change the title?”

Oh, great, Hogarth… I looked up from my computer screen only to find my office completely empty. Blinking I started to wonder if I’d taken to imaging my imaginary gorilla.

“Nope,” came his rumbling voice from behind me. Turning about in my seat I watched as Hogarth squeezed his way through the window to my office. The third floor open window.

“Hogarth!” Would I ever get tired of saying that? Yes, I already had. Would I ever get to stop saying it? One remains eternally hopeful. “Why are you climbing in my window?”

Pivoting to put his feet on the floor he rolled his eyes at me. “Because I’m a gorilla, duh…” Moving past me, making a beeline for my fichus he said, “Besides the elevator is out of service and you need a badge to use the stairs.”

Sigh, I did ask. “Hands off the fichus!” Hogarth turned to give me a pained look. “Why are you here?” I asked.

“Why not?”

Sigh. I decided to ignore him and turned back to my computer. I had a 1000 business cards to order.

“You know,” Hogarth drawled. “I’ve been thinking about a career change.”

Okay, that got my attention. Maybe he’d decide to take up flying and would be so busy with flight school he wouldn’t be around to bother me. “Oh?” I said hopefully.

He nodded, turning to run a hand across the small wooden conference table beyond my desk. “Yeah, I was thinking of being a beaver.”

“You can’t be a beaver, you’re a gorilla!” I snapped. Now he was just being silly and I didn’t have time for silly.

“What? There some law that says a gorilla can’t change careers?”

“Hogarth, being a beaver isn’t a career, it’s a species. You want to be president of the US then more power to you, but no amount of wishful thinking is going to make you a beaver!”

Hogarth turned around and gave me one of those smiles. You know, the one. The one that tells me I’d just walked right into the lesson he’d been trying to teach me. “You’re right. I’ll always be a gorilla, can’t fight birth. So were you born a project manager?”

Yeah, that smile…

 

WHAT’S IN A NAME?

Regular readers will recall that I’ve recently been at the SFAgile2012 conference. Something I didn’t cover in my prior blogs, on that conference, was my own loss of words to describe just what I did. When you’re surrounded by a room full of agile and lean visionaries, coaches, inspirational and thought thinkers, describing yourself as a “project manager” not only feels inadequate, it can make you feel unclean. My twitter handle didn’t help me feel any better. When I first joined twitter, I was damn proud of my PMP certification and it made perfect sense to use JBC_PMP. When in a room full of people who  think agile certifications are not worth the paper they are printed on, imagine how one feels to advertise that you have that “waterfall” certification.

In short, I find myself unsatisfied with the description and title of Project Manager (or Program Manager).  It’s the title I’ve held for the majority of my professional career and still hold in my day job. This isn’t a new dissatisfaction,  I have grappled with this before in the “Armchair Gorilla.” In the comments of that blog Tobias Mayer ‘s suggest it was time to change what I called myself and while I realized he was right, I didn’t have a good term to use it its place. Like it or hate it, it’s the title of common use and HR doesn’t argue about paying me.

Attending SFAgile 2012 made me question all this again. This was in no small part from attending Tobias’ talk on “The Why of Scrum.” In this talk he expands on his earlier blog on Scrum not being project management (see below). Again I was left me hanging by loose ends. I can’t argue with Tobias that the strict PMBoK definition of a PM doesn’t have a lot of purpose in a pure agile shop. Thing is, where does that leave me? I’m not an engineer turned PM. I’m not a Wharton MBA with business plans spewing forth from my mouth. I’m an ex-art student, customer support guy who grew into a role that most people call project management. So is there a place for me in this emerging world of radical lean agile management?

Yes, yes there is. Because I’m not my title, I’m something else. The question is what? You really need to go back to “Armchair Gorilla.”  and my “I’m R2-D2 ” blog to get my full discourse on what I see as my role. The short form is I’m the guy who helps the team be excellent. It’s not my job to be the super star, it’s my job to help the team be stars. This can take many forms, from dealing with the overhead process (past a certain size, nearly all companies have “process”) so they don’t have to, facilitate communication, battle IT to get the servers back up, or even make a double cappuccino with a twist of lemon if that’s what’s needed.

The question is: What the heck do I call this role?

Let’s take a look at the language we use, and the problems inherent to them.

Project: Even in the lean and agile space we still end up defaulting to this word most of the time. It is a catch all word that sums up “what the heck are we doing?” as well as all the overhead baggage needed to put a product out to the customer. The biggest flaw I see with this word is that to often it is equated only with the development effort. A project starts when the developer starts to build and ends when development is done. Projects are so much more. From the first idea to the first delighted customer is all part of your project.

Unfortunately the word also has a fair amount of negative baggage tied to it. The word project summons up visions of rigidity, sequential flow, punishing process and all manner of ills that can befall the creation of something that delights the customer.

And “program” has pretty much all the same baggage, so let’s just lump it all on one baggage train for now.

Manager: We only have to look to Dictionary.com to see the first glimmers of the problem.

“A person who has control or direction of an institution, business, etc., or of a part, division, or phase of it.”

Notice the distinct lack of the word “people?” One of the other definitions points to the word “Manages” and the 3rd definition for Manages is

“to dominate or influence (a person) by tact, flattery, or artifice.”

Ooh! I get to DOMINATE! Yeah!. My people are just assets like my computers. Can I start calling our Health Care provider “People Tech Support?”

The word manage has come to imply control over people and that’s a huge problem. Manager Tools has long maintained that “Role Power” is a flawed tool for good management. You need to have a relationship with your people if you are going to be successful. Just by their very title, we set managers up to fail from the get go.

Project Manager (Program Manager):  I know! Let’s take two words, that  already have issues, slam together and we’ll be bound to have recipe for greatness, right?

No, no you won’t.

Even if we don’t acknowledge all the bad baggage that has grown up around this title, we’d have a hard time justifying the use of the title to define this role. The title has no human factor in it. There is nothing about the title that talks to the important work that this role does. There isn’t anything in the title to indicate you are there for the team.

Project Leader: “Take me to your leader.” When the alien ask you this, I don’t think they want you to take them to an effigy of MS Project. You can’t lead a project, because a project isn’t a person. Add to this, you’ve got the hole leader issue. You see I own a horse. That old saying of “You can lead a horse to water, but you can’t make it drink?” It’s a load of horse poop. If a horse doesn’t want to move, you aren’t moving it, at least not in a straight line (we won’t get into horse training here, wrong blog). Instead I tend to think of this role as more the person who asks the horse “where’s the water?”

Team Lead: A title that has become synonymous with “un paid” psuedo-manager. The best coder is the team lead. Not because of any skill with the team, just because he can crank out more lines of good code in a day than anyone else. Let’s just leave that one on the cutting room floor and move on.

Project Lead: We can leave Project Lead in the same cutting room pile as Team Lead. It’s got the same issues, on top of not having any people focus.

Coach: “Put me in coach, I’m ready to go.” Coach is a good word. In the literal sense it is someone who trains, though really a coach is more of someone who helps to bring the best out of you. The problem comes when you try and modify it, in order to give it more description.

  • Project Coach: “Come on, Gantt chart, give me ten more sit ups!” You can’t coach a project, so this doesn’t work to define this role.
  • Agile Coach: “But our project is waterfall.” Very limited in its scope.
  • Lean Coach: “Let’s burn off those calories.” See Agile coach.
  • Waterfall Coach: “This is your barrel, the entrance to Niagara is over there.”

Coach might be a good word, the question is “Coach of what?”

Facilitator: Another great word. It’s issue is more in the baggage of its other uses. Facilitating a project planning session is just what this role should do. Facilitating conflict between the teams. Facilitating communication with the stakeholders. Like a good catalyst, a facilitator causes activity to happen, without itself being effected.

The worry is that the title has a well established place in the business world. It is considered a specialist and not an “always there” job role. Can it rise above these preconceived limitations?

Project Coordinator: We already have beaten the word project into glue. The word coordinator, on its surface seems like a good word. Non-threatening, more passive than active, implies working with things outside oneself. When you dig in though, there are two things you run into. The first is the baggage. In the formal project management world, a project coordinator is an low or entry level position. Project coordinators work for project managers. This kind of baggage makes it a bad term to use for this role.

Then we look at the dictionary and are forced to scratch our heads. “Coordinator” points to “coordinate,” which points to “coordination.” This in turn points to “coordinating” or “coordinated.” Which points back to “coordinate.” Circular logic and I still don’t know what your job is!

Scrum Master: Tobias Mayer (@tobiasmayer ) wrote a great blog titled “Scrum is not Project Management” to which I wrote the reply blog “Armchair Gorilla” where I  ended up agreeing with Tobias (after much gnashing of teeth). This blog is really an extension of that thread.

However the question at hand is if this title serves to describe the role. The answer is, “no, it cannot.” First off is the word scrum. Unless you are using scrum, then it isn’t an appropriate word. Second off is the word Master. Anyone who knows anything about getting a CSM certificate knows that you are a master of none. Most likely the entire title came about as a riff on “Master of Ceremonies.” Unfortunately it has lost that connection and the title of Scrum Master, even in the narrow confines of Scrum Teams, has dubious value.

Servant Leader: I’m pretty sure I’ve put down in writing that I love the essence of this title. Having started my career in customer support, I have always held onto the roots that I am serving my customers in what ever job I do. And who my customer is can be very broad. I think of my team as my customers. If I don’t help them, I have failed my customer.

I just don’t like the title itself. Servant is tied up in centuries of toil and oppression. Am I the team’s serf? Do I polish their shoes and lay out their best coat for the evening meal? And then the word Leader has its own issues.  As I touched on above, it has connotations of being “in charge” when the reality of this role not about being “in charge,” it’s about empowering.

Agent of Change (Change Agent): “Secret agent man, secret agent man…” Other than the obvious need for another gratuitous joke, this is a term we need to tackle as Change Agent has become a common term now. But what does it mean? I saw a great comic that had a person and death. The person said “Oh, no, it’s the Angel of Death.” To which Death replies “I ‘ve changed my name to Agent of Change.”

I don’t know, “change agent” just seems a bit too disruptive. It tends to  make me think of a less flattering term that I’ve been called in the past (for polite audiences we’ll call this term “Fecal Aggregator”). Change agent implies that things need to change, when sometimes you just need to tweak or adjust. To grab onto the Lean Startup parlance, change agent would seem to always imply “pivot” when sometimes you need to “persevere.”

Sweet suffering succotash! Where does that leave us? 

Yes, finding a name for what we do isn’t as easy as it looks. In fact I don’t have the answer (Put the slings and arrows away). What I do have is the next step in the exploration.

Of course if you’re reading this, you know I’ve styled myself as “The Gorilla Coach.” It works only because of the web site and the blog I’ve created over the last few years. Because of Hogarth, I have a great conversation starter when I answer people’s “what do you do” question with “I’m a Gorilla Talker.”

Thing is, I don’t think Gorilla Talker is something that will work on broad scale. For the limited nature of myself and this blog, it works. When coaching people, it works. When talking to someone in the 55,000 person company that is my day job, it kind of falls a little flat.

So…

Catalyst Agent / Catalyst Coordinator / Catalyst Coach:

The word Catalyst has some interesting definitions. Two, in particular, stands out to me.

  • “something that causes activity between two or more persons or forces without itself being affected.”
  • “a person whose talk, enthusiasm, or energy causes others to be more friendly, enthusiastic, or energetic.”

“Without itself being affected”: I like this! For one it implies I’m not using myself up. Too many projects have I poured my heart and soul into, only to be left sorely wanting in the end (or laid off in one case, despite the project being a complete success).  For a another, it means I’m not the focus. I’m helping others, not directing others.

“a person whose talk…”: I so want to be this person. That just sounds like the coolest job description in the world.

“What do you do?”

“I cause others to be friendly and enthusiastic.” It reminds me of a Manager Tools quote (which I shall now proceed to butcher) that goes something like “I’ll trade 90% expertise and 10% enthusiasm for 90% enthusiasm and 10% expertise any day.” If I can bring the best out of the team, company, project or product, then I’ve had a great day.

I just don’t know if I’m an Agent, Coordinator or a Coach. Should I be using a spy camera, holding a clip board or blowing a whistle? One thing I do know, my Twitter ID no longer fits me. So with a nod of thanks to the old, I welcome in JBC_GC as my new handle.

 

What do you think of being a Catalyst?

 

Note: All comments are moderated.

The Gorilla Manager’s Survival Guide to Going Agile

“What do you mean I have to wait until the end of the sprint for a report?”

John gave a nod. “Uh huh, when we do the Sprint Review we’ll be have the Feature burn down charts, as well as demos of what’s been built and a report on any technical impediments.”

“But that’s not until the end of next week, I need to brief the VP on where Project Myrmidon stands.”

John looked truly apologetic. “I don’t have anything to report until the sprint is over. You’ve got the reports for the last two sprints and you know what we committed to for this sprint. Until we’re done, I can’t compile the external report. I’d just being making up a report right now, is that what you want?”

I sighed. “No, of course not.” In reality I did want him to make something up. I didn’t want to tell the VP he had to wait another week and a half to get his status report. The VP was scary and I didn’t like explaining to him why he had to wait for anything, even if it was the way the process worked. He was the kind of guy who didn’t want to wait for anything. He would say jump and expected you to phone him from orbit to ask if that was a high enough jump.

“Need anything else?” John’s question cut into my self misery. He was standing patiently in front of my desk. When I looked up at him he said, “Remember, I need to leave early today?”

I waved at him, “Oh, right. Go ahead.” John left me alone with my thoughts. This was the fourth time in two weeks he’s left early. I wondered if anything is wrong.

“He’s taking a Community Emergency Response training class. He wants to be more active in the community.” Hogarth’s deep voice cut through my thoughts and derailed the train I’d been on. The gorilla lumbered into the room, pausing only briefly to snap a branch off my fichus before he continued on to perch in the sun drenched window ledge.

“How do you know that?” I asked.

Hogarth shook his head, “Gorilla secret. Besides you’d know to if you were paying as much attention to your team as you do to your precious status reports.”

I glared at Hogarth. “What do you mean? I see my people every day. I know what’s going on with every project and where all the risks are. How can you say I’m not paying attention?” I waved out the door, “Heck the real problem is this damned agile roll out. Ever since it got going I have no idea what’s going on. Jake and I were just complaining about it over lunch. We don’t have the same control we used to, it’s driving us mad.”

“And yet you don’t know that Molly is engaged, Max at war with IT and John was taking CERT training.”

I blinked at Hogarth. “You mean I, like, have to talk to them ?” I felt a cold shudder run down my spine at the very thought of it.

Hogarth pointed the denuded fichus branch in my direction. “Let me ask you this. What reports to you, projects or people ?”

I stared at him like he’d just grown a second head. “What kind of question is that? Of course I have people reporting to me…” I closed my mouth with a snap.

“Oh…”

 

Good Managers make for Good Agile

Management has been the butt of jokes, derision and scorn pretty much since some Mesopotamian chieftain delegated a cattle raid to his incompetent son while briefing his best warrior to keep his son out of danger and really get the job done. For the butt of all the jokes it has been, Management has also been where many of the worlds greatest leaders have risen from. The Duke of Marlborough, the Duke of Wellington, General/ President Charles de Gaulle and General/President Dwight Eisenhower all came out of “middle management” positions and went on to help change the face of the world for their time.

Whether you love or hate management, whether you think agile/ lean will do away with management, the reality is right now management is still a pervasive part of our world. This means some fairly important things.

– Adoption of new ways of doing business is going to be a lot more successful with management support.
– Managers need to learn how to work in the agile/lean world.
– The previous two bullets are inexorably linked together.

In short, managers need to learn how to work with their people again. It is through helping the team that we will all succeed. Stop focusing on the work and focus on the people doing the work. Through this can managers become a key to making a better world.

Psst… That was the passionate call to action part.

Okay, great speech. Rah, rah, rah. But speeches don’t make change.

No, no they don’t. Which means you actually have to do something.

And now for the practical tools to rise to the call.

Enter Manager Tools
Manger Tools is a website, a series of podcasts and a very dedicated group of people. When I look back on how I made the shift from drone worker to change agent and leader I can point to two defining moments. One was taking a CSM course and finally “getting” agile. The other was discovering the Manager Tools podcasts.

Focused on the principles of being effective and giving actionable advice, the Manager Tools podcasts have helped me put my career on track, to be a better manager and I think to be a better person. The principles and lessons of Manager Tools helped to form my own personal belief that if you help individuals be more effective, they will help make a better team. A better team makes for a better project and a better project makes for a better product. Better products will lead to better businesses and I businesses built on these foundations will help lead us to a better world.

Now with over 500 podcasts, years of blog posts, and a huge community forum it can be daunting to know where to start. Fortunately, Manager Tools has this covered. I also have some additional MT podcasts that I highly recommend as critical must listens.

The Manager Tools Trinity:
In true Douglas Adams fashion, the trinity is made up of four components. It really did start out as a trinity at one time. Coaching became part of the mix a few years back and I think these days the people at Manager Tools tend to refer to this as the “basics.” One thing basic about them, is how basic it is to pick them up and start using them. For ease of listening, Manager Tools has bundled around 20 podcasts into a special “Manager Tools Basic” feed. It contains their core starting points, including the Trinity (all four parts).

 

One on Ones: Two key secrets sauces at play here. 1- Meeting with your directs once a week, like clockwork. If there is a conflict, reschedule. Do everything you can to hold it. 2- The format is ten, ten, ten. The first ten minutes is the direct talking about whatever they want. The second ten is the manager asking questions he wants answers to. The last ten minutes are to future development. Project Managers- You can use O3s as well. It just takes a couple of minor changes to make it a perfect meeting for working with your project team.

The Feedback Model: The Manager Tool’s Feedback is a lot like a one shot agile retrospective. It allows the manager to identify behaviors (good and bad) and provide a response to that behaviors impact. The most powerful part of the Feedback Model is it doesn’t look to correct what has happened. Like a good retrospective, feedback is looking forward to how things can be done better in the future. Encouragement, not punishment. Project Managers- There is a modified version of this that can work with your project team.

Delegating: We’re terrible at delegating. We don’t do it well. We often delegate the wrong things. We often (very often) don’t let go when we delegate. In short, we end up strung out over a massive string of responsibilities and create all sorts of problems, not the least of which is being a single point of failure. Let us not forget the great Dilbert wisdom of “If you make yourself irreplaceable you will never get promoted.”

Coaching: Yes, that’s right, managers should be coaches to the people on their teams. Mark Hortsman, of Manager Tools, says that one of the greatest signs of a successful manager is that he gets his people promoted. Helping your team grow, learn and prosper is a vital part to being a good manager. And like good coaches, the goal is not to lead or drive them there, it is to make the possibilities possible.

Jump Starting Internal Customer Relationships : This two part podcast is a must listen for anyone joining a new company, new department or new project. This is one of my first go to actions when brought in on a failing project. Few would argue against syncing up with your stakeholders. The Internal Customer Interview process takes this to the next level by giving you a standardized format and set of questions to ask all your stakeholders. Through the repetition of the same questions you create quantitative view of the situation.

The DISC Model in action: DISC is a quadrant based behavioral model. Having used it for several years now I can attest to it being a model that actually works as opposed to being a money maker for “specialists” who come in to “fix” your organization. You can get a full assessment online for about $30. Manager Tools has over thirty podcasts devoted to interacting with people based on the DISC system. Hands down this has been one of the most valuable tools I’ve picked up from Manager-Tools.

 

In conclusion, this is one series of podcasts that is worth going back to episode one and listening to them all. It didn’t just help my career, it gave it purpose.

Better people, better projects, better world.

Gorilla McPhee and the Groundhog

You know the nice thing about banging your head on the desk?

It feels so good when you stop…

And some days that is enough to look forward to. Days like today, launch day. The day we put our best face on and release into the wild the product we’d been working on for the last eighteen months.

You know the old joke about products? “Products don’t launch, they escape.” Well our product overpowered the prison guards and stole a tank to bust out. And I was left sitting in my office with that horrid déjà vu feeling of having done all of this before.

Because we had, on the last release.

The authentication database locked up after a hundred logins, just like last time. The servers couldn’t handle the traffic load of a major part of our user base logging in at the same time, just like last time. I could go on, only my head was getting sore and it really didn’t matter. Oh, sure, we’d improved the build process, getting down to twenty-four hours from build to completed tests. Other than that, though, we had made almost the exact same mistakes as last time and as certain as the sun comes up we would make most of them again.

This was all like some bad metaphor, I just wasn’t sure which one.

“Ground Hog Day”

“Wha?” I looked up to see Hogarth filling my doorway. “Hogarth, what do you need?”

My gorilla lumbered into the room and took a seat on the ground next to my fichus tree. With a contented sigh, he leaned back against the wall and helped himself to a branch from the fichus. Finally he looked up at me and said, “You were looking for a metaphor to describe your problem with déjà vu, I was suggesting Ground Hog Day.” He held up a finger, ” The movie not the actual day.” His teeth stripped a piece of bark from the fichus branch before he continued, “Every time Bill Murray went through his day, he learned something. Eventually he even started improving things.”

Hogarth gave a wave towards the hallway and the other offices. “Stop trying fix everything all at once, it won’t ever happen. Pick one thing, and fix it. Then repeat the process again and again.”

“Augh!!!” I threw my hands up in the air. Had I any real hair to speak of, I’d probably have been yanking it out of my head right then. “Am I ever going to be rid of you? Am I doomed to a life of moral correctness being delivered to me by an 800 pound gorilla?”

Hogarth folded his hands over his belly and gave me a soothing smile. “When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”

Oh no! I wasn’t going to be tricked this time. He’d made me look like an idiot too many times with his obscure historical quotes, “What famous philosopher said that?”

Hogarth smiled at me, “Nanny McPhee.”

“Huh?”

 

Coaches (Agile, Lean, Business) are like Nanny McPhee and Businesses are like the Ground Hog Day movie.

Last week I had the privilege to attend the SFAgile2012 “Unconference” in San Francisco. It was a great experience and I am still processing everything that I took in. In the coming weeks I hope to write about more of my observations and personal discoveries, like being caught in the middle of converging philosophies, the agile survival guide for functional managers, the need for a new definition of agile (who knew manifesto was such a highly charged word), or even a humorous look at the word fachidiot.

Right now though, I want to tie together two threads I experienced at SFAgile2012.

Hackerpenuer – or the Ground Hog Effect

The first was Joshua Kerievsky’s (@JoshuaKerievsky) closing keynote at the conference. One of the attendees recorded his keynote and I think it is very much worth watching. No matter what your preferred methodology is, I believe Josh’s points will resonate with you. And his use of the movie “Ground Hog” day to illustrate both the problems with learning and the benefits of learning from mistakes was superb. He extended the ongoing theme of the conference, that of the cultural hacker.

Part 1- http://youtu.be/29WekhL_c44  Part 2- http://youtu.be/_ArGvKpJI8k

His use of the movie was very telling and I can’t begin to cover everything. One of the powerful take aways I had was in the power of iteration. We watch as Phil relives the same day over and over again. We watch as someone is given the chance to “if you could do it all over again, would you do it differently.” Phil could, because his iterations were short and he remembered what happened the last time he was able to make changes and experiment.

What if your iteration is nine weeks long and you don’t do integration until week seven*? That means you have to go seven weeks between each time you get to effect a change. And then it’s a lot like the theory of reincarnation. Yes, you get to live life again, only you don’t remember the last  life, so you just might make the mistakes again.

*Yes, we know it’s a bad idea to wait so long for integration testing. It works for this example though.

What’s our Goal? – Mission – Values – Purpose

The second thread was one that I was unable to put words to during the conference. It was not until after, when reading Olaf Lewitz’s (@olaflewitz) Twitter profile, that I was able to put words to the thread. Even now, I find myself struggling with words I am happy with. For now, our Goal through Mission, Value, Purpose (MVP, yes I planned that) will have to do.

Olaf’s Twitter profile reads: “Linchpin. @agile42 Coach. When you need me, but do not want me, I must stay. When you want me, but no longer need me, then I have to go. (NannyMcPhee)”

Nanny McPhee is another movie, one in which Emma Thompson plays a character much like Mary Poppins. If you remove all the sugar and spice and everything nice and replace it with warts and boils and in your face honesty. McPhee could be the living embodiment of what happens when an organization embraces Agile/Lean methods. It is often said that Agile is a great tool for revealing the warts in your organization. And for those that stick with it, they find that the warts are not really that big  compared to the beauty of effectiveness they can achieve.

Nanny McPhee is also the perfect coach. She doesn’t try and change you. She creates opportunities for you to see change, she asks you the questions you are asking yourself, and she helps you to see the change you want to make. She doesn’t lead a horse to water, she asks the horse “Where is the water?” (After sneaking up on the horse in his stall and apologizing that the door was open.)

This brings to the interesting question. One I am still not sure I can even put properly into words. For want of something I’ll just settle for “Who are we, what do we do, what is our purpose (Hmm WWW. I think MVP is better). Really though I think the right question is, “What is my goal?”

We already have an idea of Olaf’s purpose through his espousing the McPhee mantra.

Simon Marcus, the CTO of The Library Corporation, summed it up as “Continuous learning and respect for others.”

Joshua Kerievsky’s (@JoshuaKerievsky), following his Hackerpenuer theme has “Hacking, Hutzpah, Happiness, Hustle, and Health.” (Yes, he hacked Chutzpah to make it work).

Illan Goldstein (@iagile), an Asutralian Agilist, responded to my own goal statement with “To constantly improve and to never go backwards.”

Which brings me to my goal. What is one sentence I can use to sum up my goal as a program manager, coach, facilitator, <insert title here>? For me, I say “My goal is to spend every day trying to make myself obsolete.”

This is not my personal life goal (my wife would object). This is my goal in working with teams and a company. After a twittersation (conversaion on twitter) with  @iagile and some others, I realize that even something so simple can lead to confusion. Words are amazing.

My thoughts are that if I am always trying to make myself obsolete for my current team/org, then I am working to better myself, better the team, empower the team and improve the value stream. It is almost certainly an unattainable goal and I think that is just fine. It is not the goal that matters, it is the journey that matters.

So with two popular moves, we see answers to change, the value of short iterations, the value of revealing the warts, and some clues to what is our purpose as coaches.

 

> I will always strive to not be needed. If I ever am not needed, I will be filled with joy and contentment for the world will surely be a much better place. <

 

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

The Gorilla always sits in the front row

I stuck my head into the room to cast a quick glance around. The presentations wouldn’t start for another hour and the room was empty of all save some facilities people setting up the AV. Smiling, I ducked through the doorway and made for the best seat in the house. The middle of the back row.

I merrily pulled out my laptop, chortling at my luck.

“You do know that they don’t expect more than fifty people and this room can hold one hundred?”

Good seat luck, bad gorilla luck, guess you can’t win them all.

With a deep sigh I looked up from my computer. Hogarth was taking up a good two spaces at the front row center. Half marveling at how I could have missed an 800 pound gorilla and fully dreading just what was about to transpire I opened my mouth. “I know that, but if I didn’t get here early, the back row would have been all filled.”

Hogarth gave a kind of coughing grunt. If I had to guess I would have said it sounded a lot like those fake coughs people give, while they say some other message. Usually an unkind message. “There’s no one in the front row yet, why don’t you sit up here?”

“This isn’t a Springsteen concert, Hogarth, there is no way I want to sit in the front row.” I gave a vague wave towards my gorilla and the whole front row. “What if these presentations are boring? Anyway, I’m so busy I need to keep an eye on email and it would be rude for me to not be paying attention from the front row. And what if I need to leave?”

Hogarth raised an eyebrow, his expression all but saying, “Seriously?” Recovering from that, he leaned back in his chair, crossed his hands over his chest and fixed me with his ‘gaze of learning.’ “Let me get this straight. You call yourself a radical change agent. You espouse open trust and honesty in the team. You believe in free flow of communication.”  Hogarth narrowed his eyes, “And you don’t want to sit in the front rom because you might be bored?”

When an 800 pound gorilla says it like that, it really does sound bad.

Why are we afraid of the front row?

Go to any training, any “all hands” or even any conference (the ones people want to really be at) and odds are better than even that the back row or the middle row will fill up well before the front row does. It’s practically a law of business, right up there with “buy low, sell high.”

I never really thought about the phenomenon until today. I used to be part of the back row posse. I’d sit back there so no one could look over my shoulder at what I was doing on my computer (which was often usually nothing to do with what was going on in the meeting.) I stopped sitting in the back row when I made my own personal discoveries about laptops in meetings (I can see you gorilla). Not being distracted by my computer, I started moving closer and closer to the front, realizing that it was much more engaging and effective to be there and be involved. These days I rarely sit more than three rows back and most of the time I go right for the front row.

I’m currently attending SFAgile2012 . This is not a conference for agile/lean beginners. There is no “Intro to Agile” or primers to guide you. If you don’t already know and believe in agile/lean then this is not the place for you. These are the men and women who live and breath the principles of trust, honesty and openness.

So imagine my surprise when the meeting rooms filled up and the weight of the room was decidedly canted to the rear. I was late to one session and it wasn’t a problem at all, plenty of room left. In the front row. I was more than a little perplexed. Wasn’t this a conference of change agents? Challenge assumptions, innovate, adapt, improve all being watch words of the day.

So never being one to shirk from talking to the gorilla in the room, I took an opportunity to chat with a couple of other attendees on the subject. It was an interesting insight into the human psyche. As much as agile and lean push the envelope, we are still human beings and we are not perfect. “What if I don’t like the session, I’m trapped because I can’t leave without being rude.” “Maybe I want to hide and not be the focus.” I don’t want to block the view of those farther back.”

Fascinating. Even we who are leading the charge for innovative change find ourselves wrapped up in our all too human foibles. We don’t want to hurt the feelings of a presenter, so you sit where you can easily slip out. If we’re being honest and open, then we vote with our feet. If the session isn’t to your taste, then leave. Having done my fair share of presentations, I can tell you that the presenter will notice if you slip out from the back row as much as front row. As Agilist (Leanists?) we should be open and unafraid of “being the focus.”

I firmly believe the back row should be the last row to fill up. And as agile/lean practitioners, we should be setting the example of good engagement.

I’ll save you a seat at the front.

A Gorilla Primer: What the heck is Agile?

“It’s all rather simple.” I said confidently. “It’s a process to maximize our transparency so that we can deliver the maximum effectiveness of end purpose value to our constituents while ensuring the highest possible predictability in deliverable milestones .”  

Hogarth cocked his head to the side, “I’m not following. I thought this was supposed to be easy?” 

I tossed my hands in the air energetically. “It is! That’s the beauty of it. Why the framework for one implementation can be summed up in ten minutes.” 

“Really, so what’s the value?” Hogarth asked. 

“Total optimization!” I beamed. “Using a collaborative team structure you generate value in an iterative cycle that completely optimizes your process and maximizes customer return.”  

Hogarth looked at me for a long moment. Finally he reached up to scratch his chin. “Huh… I’m still not sure I’m following. How is this different from waterfall?”  

I jumped up “Totally different! It will change the world!” 

Hogarth shrugged, “How?” 

I let out an exasperated sigh, “Have you been listening to anything I’ve said? Haven’t you read anything about this?”  

He nodded, “Yep and I’m still not understanding what’s in it for me.” He opened up his arms, “If you’re going to sell me on a new way of doing things, you have to tell me what’s in it for me and you need to use small words.” 

“What’s in it for you? Why that’s….” 

Well damn, the gorilla was right again. 

What the Heck is Agile?
A blindingly simple question that is a lot harder to answer than one might think. Trust me readers, I will get to the answer, just bear with me a moment as I expound.

I’m an experienced agilist, I speak about agile often, and I write about agile regularly. And the other day I found myself trying to explain agile to a program manager who had zero knowledge of it.

Wow… It’s not that easy.

First problem, where to start? I took part in the May 11th #PMChat twitter chat, which had a topic of “An Intro to Agile.” It was a great Tweetchat, with a lot of valuable information. Only it would have been better called “An Intro to Scrum.” That’s great, it was a good topic and judging by feedback, very informative.  Only Scrum isn’t all that is agile. When discussing agile, do you start at the nuts and bolts, or do you start at the overarching philosophy?  

Or maybe… You start with the user.  

User Stories: Skipping ahead to an advanced lessons, we find that User Stories are different from requirements in that they are focused on the benefit given to the user. So maybe we should be using the same concept to explain agile. Today is version 0.1 (zero dot one [zed dot one for British folks]) of my agile primer.  

Let’s look at our users and what agile can do for them: 

Company President- Do you want predictability? Do you want happy customers? Do you want happy shareholders?

Agile is a company initiative that creates more predictability in releases and allows the company to quickly adapt to the customer’s needs. Through happy customers your company has happy shareholders.  

Product Manager- Do you want to be able to change your mind? Did your customer change their mind? Do you want what really matters, when you need it?

Agile is a flexible product design process that allows you to adjust the product to meet changing customer priorities. What ships is what the customer really needs (and will buy).  

Manager- Do you  really want to be looking over your team’s shoulder every day? Do you want to help your people grow, not just make the next code drop?

Agile gives your team the ability to what they do best, create. It gives you the ability to do what you are best at, helping your team grow.  

Project Manager– Are you tired of chasing down everyone with the age old “What’s your status?”  Are you tired of living in the DMZ between product management and engineering? 

Agile is founded on transparent communication and puts deep focus on collaborative solutions that have the whole team working towards a common goal.  

Developer– Would you like development model that puts the power in your hands? Do you want to decide how to build something? Do you want management to listen to you when you say it will really take three weeks?

Agile lets you be directly involved in helping to define how something will get built and even what gets built. The company puts its trust in you to make decisions and listens to you when you say how long something will take. Schedules are based on what can be built not some artificial line in the sand.
Great, so what exactly is Agile?
Ah yes, once we get past the benefit we still have to figure out just what agile is.  

An early attempt I had at a one line summary is: “a customer focused, iterative process that is executed through a collaborative effort of the team and company.”
Yeah, I know, with that kind of double speak I should be in politics.

Agile is:
  • Listening to the customer throughout the entire development process, not just at the beginning.
  • Focusing on the team. A better team makes a better product. Trust in the team.
  • Building with GPS. You’re constantly making sure you’re on course.
  • Learning from mistakes, not just writing them down at the end of the project.
  and –
  • Not new. The term is new, the ideas reach back decades. We owe the Agile Signatories for helping bundle the concepts into a single word.
  • Not a methodology. It’s a set of principles and values. Below these are frameworks like Lean, Kanban, Scrum and XP.  

At its barest essence, that is what agile is. It’s not some secret, make it all perfect, sauce. It’s hard work and incredibly rewarding. It’s moving from shareholder value to customer value. Go read the Agile Manifesto. It’s not about process, it’s about results.

Okay, and?…
Right, that and four dollars will buy you a cup of coffee. What do we do with this? Good question. Agile itself isn’t a solution. Agile is a mindset, a way of thinking, of interacting. You still need a framework to work within. The are four common agile frameworks, Scrum, Kanban, XP and Lean.

In a nutshell:
Scrum– Is characterized by its iteration cycle. At the start of a sprint (1-4 weeks), the team commits to working on a certain amount of the Product Backlog (Everything we want built). They meet each day to review progress and impediments. At the end of the sprint (iteration) they demonstrate working results (no PowerPoint). Then the team reflects on how the team did and what can be done to get better.

Scrum can be very good for new development, where uncertainty is high, change is constant and the customer is involved.

Kanban– Kanban has evolved from Just in Time manufacturing concepts. Its primary characterization is the WIP, or Work in Progress, that limits what can be pulled from the Queue (What needs to be done). It does not work in iterations, instead working in available workload. By limiting work in progress, you limit waste and generate greater focus by reducing multi-tasking. It’s other driving factor is it starts with where you are now, and works to get you to a better process. Where most frameworks are replacements for existing methodology, Kanban focuses on continuous, incremental improvement from where you started.

Kanban can be very good in maintenance, where each item is often unique.

XP– Extreme Programing is probably best known for the concept of pair programming. XP is known for pushing the limits of traditional practices (hence “Extreme”). It also uses short iteration cycles, typically, one week max, as well as demos and retrospectives. It is also heavily leverages code reviews, unit testing and automation. Typically more so than Scrum. The average person will see little external difference between  XP and Scrum.

XP is very common with start ups and for projects that extremely dynamic or have few starting requirements. You are rapidly prototyping to a final product.

Lean- This practice is best characterized by the elimination of waste. Anything that does not create value for the end customer is considered wasteful and a target for elimination. It’s a “do more with less” framework that at works primarily thanks to strong principles that oversee the structure. Toyota’s Total Production System is the most common example of Lean.

Note: Some will argue that Lean isn’t agile. Not being an adherent to any one framework I see Lean as sharing many of the same principles and thus put it under the loose umbrella of agile. It’s easier than calling them all “customer focused, iterative development practices that focus on the team.”

Lean is most common in manufacturing, where the product is relatively fixed and the improvements are focused on how to produce the product better.
Anything else?
Oh, Gorilla, yes. There are stacks of books and gigabytes of blogs on agile. I can’t even begin to scratch the surface with all my blogs. Let me leave you with some additional resources and one last thought.  

Elements of Scrum– Great primer book on the Scrum methodology. I reviewedit last year. The authors also just released a 50 page super primer. Only $0.99 on Kindle.
Mountain Goat Software– Mike Cohn is one of the leading educators of agile. His web site is full of information.
Agile Leadership Network– Find a local chapter. Meet people who also believe in changing the world.
Wikipedia– Seriously, the articles on Agile are very extensive and a great way to get started.
One last thought: All the above is a fairly basic and fact based review. I’ll want to leave you with why I use agile. We’ve spent several decades with companies focused on shareholder value. I think the time is coming to swing back to focusing on customer value. We’ve also spent the last several decades focused on getting more out of our teams. I think it is time to start giving more to our teams.

I think agile is the key to these changes. I think the values and principles of agile and lean will change the world for the better.

And I want to help.

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

The Gorilla Product Owner: It takes a village

“Bob,” Jake’s tone was almost plaintive. “You’re killing me here. I thought we had this all sorted out. Didn’t we just spend three days doing ideation work?”

Bob looked pained, he wasn’t happy and it showed. “We did and I thought we were sorted as well.” He gave a shrug, “Sales got wind of the requirements and threw a royal fit that we weren’t addressing performance on the OutDate hardware.”

“They do realize it’s a fifteen year old platform?”

Bob nodded, “And they insist it’s a must have to support ‘key’ customers.”

Jake grumbled, “fine, that explains that. What about this other stuff?”

Bob winced, “My boss isn’t happy with the strategy, he wants to alter course.”

I glanced over the new proposal. I made a note to talk to Bob about the concept of the word ‘alter.’ This plan was nearly a 180 from the previous one.

Jake threw his hands up in the air, “I give up. Every time I think we’re settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?”

I could see Bob stiffen at that one. He didn’t respond, even though I could see he was rankled by the comment. I think he didn’t respond because he knew he really wasn’t in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.

“Sounds like you need to start the project before you start the project?”

“What is it this time, Hogarth,” I asked with no small amount of dread. Turning to face him I continued, “I’ve got Bob fully engaged with development, they’ve been meeting regularly. I’ve got an honest to goodness PO led product backlog for the first time ever.” I waved at the business plan on the screen, “and it’s all been tossed out the window. What’s the point? We are halfway through development and this is a huge shift in direction.”

Hogarth nodded, “Which is why you need a project before the project.”

I blinked, “Wait, what? That’s Big Design Up Front! We’re agile here!”

Hogarth gave me a huge, ivory filled yawn. “We covered this already, remember? Garbage in, Garbage out?”

I pointed a finger at Hogarth, “look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!”

Hogarth nodded, “And who else helped?”

“Huh?”

Hogarth gave a long stretched before fixing me with his dark gaze again. “You wouldn’t design the features without the agile development team, why design the business plan without an agile business team.”

Blink, blink. Well dang…

 

 A Product Owner is Not an Island

Experienced agilists will of course be saying “duh” right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.

Beyond even the question of “how do you prioritize the business value of the backlog,” are questions like “what’s the business model,” “what’s the product concept,” and “where does the product owner get his requirements from in the first place?”

The product owner is not an island. He doesn’t sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be “fast”, “ultra-secure” and “cheep.” The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein’s monster than Brad Pitt.

 That’s just the way it is, you can’t expect that to change.

 It can if you make a village.

In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don’t speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?

In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won’t be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final “product” to the primary GiGo team.

Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.

Product Sponsor Customer  (or voice of the customer)
Related product managers Technical Support
Technical Architect* Marketing
Agile coach or Facilitator Sales

While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO’d at them.

Do you have your village?

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, jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP 

Don’t play Planning Poker with the Gorilla

“10 Days” Eric said.

I sighed. “Eric, you’re supposed to use the planning cards and put down a value.”

As he flipped through his stack of cards I could see him counting to himself. “Okay, fine. I think this is an 89 point task”

Sigh… “Eric, you just counted out ten cards and put that card down.”

“Yeah, so?”

I leaned forward and tried to use my calmest voice. “Eric, we’re not trying to figure out how many days right now, we’re trying to do an abstract estimate on the relative size of each story in the whole project. “

He waved his hand, “What’s the point? If we’re painting a house and you ask me to estimate how long it will take to paint the garage door I can put down a 2 or just tell you two hours. You’re asking me to use an abstract number when I already know how long it will take.”

I sat back in my chair perplexed. The problem was that I could see his point. We were tackling each task one at a time and no matter what I did, I couldn’t break the team out of thinking about how many days something would take. And I knew this was a slippery slope that led back to padding, swags and a whole slew of inefficient planning practices.  

A long meeting later I dragged myself into my office. Only to find both my chair and the guest chair occupied. One of the occupants I expected to be there, a post meeting debrief on this last meeting was much to much for my personal gorilla to miss. Seeing the black swan flipping playing cards onto my desk was quite another thing.

Flip, flip, flip “144!” Hogarth said, triumphantly.  Looking at the black feathered swan he grinned. “Hah, that beats your 21.”

“Hogarth!?” You’d think I would get tired of yelling his name. Or maybe I would just get used to his ever present level of restrained chaos. You’d think… “What are you doing with my Planning Poker decks?”

“Oh, hey there,” Hogarth turned his cheerful smile my way. “Wanda and I were just playing war.”

Tossing her last card, a 2, down Wanda slid off the chair. “I have to get back to the server room anyway, one of the HVAC’s is about to short out because a gopher climbed on the roof and ate through the power cable.”

Trying not to think of electrocuted gophers and overheating servers, I ignored the departing black swan and turned my attention back on Hogarth. “Why are you playing war with my Fibonacci cards?”

“Oh, that. Well I figured you might want them and then we just kind of got bored waiting for you to be done not estimating the release.”

I blinked at him. “Hogarth, I know you were eavesdropping on the meeting. You know perfectly well the team thinks planning poker is useless.” I tossed myself into the vacated guest chair with a sigh. “And I’m not sure I don’t disagree with them.”

“Since when have you believed there’s only been one way to use a tool?”

Blink, blink… Why did he always have to be right?

 

Story Point Estimating

This is one ofthe foundational principles of Scrum software development (and Agile  in general). Done well, story estimating can create an incredible level of predictability and transparency. A high performing team can look at a set of requirements and provide a high confidence assessment of when they will done.

But this isn’t about the value or use of estimating. There is plenty written on this and I’m not here to rehash it. I believe in estimating, just as I believe in the principles of agile and good management.

What I’m here to say is I think Planning Poker is the wrong way….

What? Come on, I’d be a lousy gorilla talker if I wasn’t willing to tackle tough subjects head on. I do absolutely think story point estimating is the right thing. I just think planning poker is not the best way to do it.

Naturally this begs the question of “why?” I have two reason for my concerns on the use of planning  poker:

  1. Each user story (feature, tasks, item) is evaluated on its own. When you do planning poker you are just looking at how long it will take to paint the garage door. You are hard pressed to look at it in relation to putting a new latch on the back gate. I think the mind is hard pressed not to assign a physical value to the estimate. “I think this will take two hours, that’s about a 3.”
  2. At the end of the day, the planning poker process occurs in an individuals head.  Yes, there is a discussion among the team, but only after each person has drawn a line in the sand. Once the human mind draws a line, it finds it hard to move that line. We’ve invested ourselves in that line.

So what the heck do you do?

Well if you’ve been following my recent agile related blogs, you’ll know I’m a very big fan of something called the “Team Estimation Game” developed by Steve Bockman. I personally like to call it “Team Planning Solitaire.” The style of the game reminds me of classic Klondike solitaire and the interaction of the team makes it anything but a solo activity (what can I say, I like irony). I will also note that while I learned this from Steve Bockman and Agile Learning Labs , I have seen some similar exercises in the last few months. Whether they are parallel development or evolutions of Bockman’s game, I don’t know.

I detailed how this game worked in “How much is that Gorilla in the window.”

At the highest level, the process starts with the story cards in a pile. Each person takes a turn laying out a new card or moving an existing card on the table. At the end, you have a line of cards in rank order. Only then do you break out the planning poker cards. Your estimates end up being based on the relation to the other stories, not to how long one story will take.

Why is the Team Estimating Game so good?

  1. Stories are estimated in relation to one another and not in a vacuum. “Is painting the garage door more or less effort than replacing the latch on the back gate? All right, is painting more or less effort than rehanging the front door.”
  2. It’s a team activity. Nothing happens in anyone’s head. It is all out on the table and very straight forward. You aren’t sitting there arguing that the Database re-architecture will take a week or two weeks. You are just trying to decide if it is more or less effort that localizing the user interface to Japanese.

At the end of the day I think Team Estimating is much more effective than planning poker. Leave the poker cards for a nice game of Klondike or Texas Hold ‘Em.

Who’s ante is it?

 

 

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

Coachin Agile Teams

 

“You’ve got to do something! We can’t keep going like this, the entire project is going to collapse in on itself.”
Eric certainly had a way of getting my attention. I had instant visions of red project dashboards and burn down charts flat lining like a patient in the ER. Eric was one of the canaries on the project. There are always those certain team members that reflect the state of the project or are the first to see a major issue. Like the miner’s canary of old, they are the first to notice or raise the issues and a smart manager learns to pay attention. These are not to be mistaken for the Chicken Littles, who can give a hypochondriac a run for their money. When a canary sings, you listen to their song.
I held up my hands and spoke in a calm tone. “Okay, Eric, calm down and tell me what the problem is. I’m sure we can get this addressed.”
Eric took a deep breath and paused for a moment, as if suddenly unsure he wanted to continue. I gave him my best supporting smile and waited.  Finally finding his voice he said, “It’s Greg, he smells.”
I blinked. “Smells?”
Eric nodded, perhaps a bit too energetically. “No one wants to pair program with him. Heck no one wants to be within six feet of him. It’s like a mouse crawled into his shirt and died. Given the last time he changed his shirt it could well have.”
I sat back in my chair, a frown threatening to crease my brow. “This can’t be happening to me,” I thought. My next thought was to look across the table again. If Brenda were sitting there, this would have been another “The sky is falling” moments and I could have dealt with that like all the other times the sky didn’t really fall. Only this was Eric, the most reliable barometer of the teams health available. It meant that either Eric had gone off the deep end or the problem was very real.
So now what? This wasn’t a slipped schedule, we didn’t have a shortage of test machines,  it wasn’t even the completely useless requirements or product manager owner was foisting on us. No, I was being asked to deal with someone’s smell.”
They didn’t cover this in project management training…
“What would coach do?”
I turned to cast a baleful look at Hogarth.
“This isn’t a football game.”
My gorilla gave a little nod. “Good thing too, cause you stink at football.”
“Hogarth you are not helping me solve this problem.”
He nodded again, a brilliant white smile splitting his face. “Nope, I’m not and you shouldn’t be either. Solving Eric’s problem isn’t going to help him solve it in the future, now is it?”
Dang… he was right.
BOOK REVIEW: COACHING AGILE TEAMS, By Lyssa Adkins
Summary:
This book had been recommended to me many times, by many people. It forms one of the core study books for PMI’s new agile certification and you’d be hard pressed to find a conversation on agile coaching that doesn’t reference this book or the author.
Like me, Lyssa Adkins is a recovering command and control project manager and this is one of the things that makes this book resonate for me. While many agile authors have always been on the revolutionary/evolutionary end of the innovation scale, Lyssa had worked in the trenches of traditional projects and speaks to all audiences. Whether you are an eccentric software coder, turned agile visionary, or a former art major, turned project manager, turned aspiring agile coach, this book will speak to you. Very importantly, it speaks right to project managers “in transition.” Based on the traditional roles that project managers have filled, the scrum master role often ends up being a place project managers end up gravitating to as they journey into agile (or are shoved feet first by events, company, etc.) so this book is a great asset to them.
With 302 practical pages of content, there is a lot to absorb. It is not an evening’s light reading. Some of the concepts and mental challenges they raised had me setting the book down so I could process. All in all, it took me several weeks to read the book as there was so much to absorb and my mind wasn’t ready for it all at once.  But there was no way I was not going to finish this book.
The book is broadly laid out into three sections and the first hint you have on what it takes to be a good coach is that two of the three sections have to do with you.
  • It Starts With You: Starting with the obvious “will I be a good coach?” question, this section lays down the ground work to open yourself up to what is needed for you to be a good coach. Along the way it teaches you a lot about yourself.
  • Helping the Team Get More for Themselves: This section covers six aspects of being an agile coach, from the high level mentor concepts to the details of how a coach can help resolve conflict in a team.
  • Getting More for Yourself: One of the things I truly appreciate about agile, is its stance on failure. Lyssa’s book is no different and this section tackles head on the mistakes you will make and that it is okay to make them as long as you learn from them. It touches on the journey and knowing when you finally get there (Hint- you never do).
The Good:
Approachable Style: Lyssa writes this book in a conversational tone and weaves in direct experience throughout the book. You constantly have a strong sense that she is speaking from her own hands-on experience and her light style makes absorbing the deep content a lot easier.
Failure is okay: She knows that the journey to being a coach is going to have its bumps and bruises and she makes that okay. Instead of feeling like you are facing an insurmountable journey to be an agile coach, she reassures you that the potholes are just part of the journey. The most wonderful experiences are not found in the well manicured aisles of a department store, they are found out in the wilds of the world.
Lots of practical tips: The book isn’t just theory and platitudes. She provides solid tips, actions and exercises. She also provides tailoring to help you deal with all aspects of an agile organization, not just the agile development team.
The Not So:
No punches pulled: This could arguably be in the good things, you just need to be aware about it. Lyssa doesn’t pull punches and she’s not going to white wash this. If you are not ready to let go of your control freak nature, this book will be hard to read. You’ll put it down more than once and walk away. You will also learn really fast if you really want to be an agile coach. It is not a job for everyone. I still want to be one, but this book certainly tested my mettle.
Broad base may not appeal: If you are a hardcore scrum master, who is totally focused in on the artifacts of scrum and only scrum, you may find this book to broad for your tastes. Lyssa comes off fairly agile agnostic. This book is about helping any team, in an agile way, and this may not be pure scrum enough for some. Again, this could be argued as a good thing. I would hazard a guess that is part of why it ended up on the PMI reading list.
The Bookshelf Index: (Where does this book when I am done reading it?)
In my computer bag: This book speaks so much to what I want to be and how I want to engage with teams that it has not left my computer bag since I started reading it. It has quickly become a well worn copy and I will continue to refer to it regularly for some time to come.
Joel Bancroft-Connors
The Gorilla Talker
Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com
You can follow me on twitter, @JBC_PMP