WikiCommons

“Compile error?!?” I mashed my hands down on my keyboard in frustration, to which the computer helpfully replied, “invalid command”. “You ungrateful hunk of ones and zeros I’ll give you a compactor error, garbage compactor style.”

I leaned back in my chair, for the first time noticing my home office was shrouded in darkness save the light coming from my dual monitors. How did it get so dark, it’s the middle of summer. Looking out my window I was dismayed to find the darkness was not caused by one of the Pacific Northwest’s famous summer rain storms. That meant I’d been trying to get this program to compile for?..

“Ten hours, give or take a bathroom break,” rumbled a voice. Being primarily a black gorilla, I’d missed Hogarth lying on the daybed.

“Ten hours? For the love of Peet, how did I spend ten hours on this?” I looked back at my screens. The compile error was still visible in the terminal window. The rest of the screen was filled with various websites and eBooks on C Sharp programming. Ten hours and I had nothing to show for my attempts to learn to code.

I turned to Hogarth, “Where’s my family?”

He waved at the door, “your wife came in about four hours ago. You handed her your check card and mumbled something about taking the kids to dinner.” He waved back at the computer screens, “I suggest you do something useful with that computer and order your wife some flowers.”

I nodded, “You’re right, that would be usefu… Hey, wait a minute. I was doing something useful.”

Hogarth grunted, “You were? “

“Sure I was, I was learning to code so that I could better communicate with the engineers I coach.”

Hogarth nodded his head, “Uh huh… So you’ve been at this what, two months? What have you learned so far?”

I glared at him. He knew very well the answer to that. I’d made only small progress in understanding the intricacies of C Sharp. Pretty much anything I had learned was in the first couple weeks of reading. The implementation of the reading is where I was stymied.

“Right,” Hogarth said. “And when was the last time you wrote a blog, went to a meet-up, coached one of your mentees?”

I stopped glaring now and turned to stare at my monitor again. It was preferable to be mocked by the compile error than to be schooled by my gorilla.

To Technical or Not to Technical, is that even the right question?

This is not a new argument. Before Scrum Master became a mainstream job title we were having the exact same conversation with project managers (see my 2010 blog, Project Gorillas are Subject Matter Experts). As an agile coach, today, I see the same argument for coaches and I also see it applying for any kind of consultant, who is going to work with development teams.

Do you have to have a technical background in order to work with technical people?

No, you don’t.

Does it help to have a technical background, in order to work with technical people?

Well, sure it does. That’s like asking “will I experience more, on my trip to France, if I can speak French?”.

However, you can be the best C++ coder in the world and if you were hired to coach a team on how to implement Scrum then you better know Scrum really darn well. My 2010 blog looked at this through the lens of project management and yet those principles apply the same to Scrum Masters and Agile Coaches. In fact, I think it applies even more in the agile context.

In 2015 there was a great article and subsequent conversation on LinkedIn about scrum masters and technical background. The main arguments, that a scrum master needs to have a technical background were “How will they remove technical impediments?” and “How do you know if the dev is lying or inflating the issue?” All right, let’s break it down then.

1. Resolving Technical Impediments:Yes, the Scrum Guide lists one of the scrum master’s duties as “Removing impediments to the Development Team’s progress”. Cut and dried, right? It’s the Scrum Master’s job to do it.Only the scrum master is also a “Servant Leader”. One of the things this means is to be a leader. If your general was always the first to storm the hill, not only would he be too busy to direct the overall attack, he could well be dead. A Servant Leader is about creating the environment where the team can succeed.

   Then we need to look at the development team themselves. The Scrum Guide says “Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment.” The development team is responsible for creating the product and they have all the skills needed to resolve this. If they don’t, they are going to be the ones with the technical understanding to work with others to get it resolved.

   The scrum master doesn’t make the faulty database go away. The scrum master helps to ensure the outside database team is available and responsive to the development team.

2. How to spot lying or exaggeration:

First off, you go back to what are the skills of a good agile coach or scrum master? Facilitation, conflict resolution, negotiation, and communication are just a few of the more notable. What they all have in common is people and the ability to work with them. After 20+ years of working as a project manager, scrum master and coach, I can pretty much tell if my leg is being pulled.

More importantly, though, is it’s again not the scrum master’s job to know if someone is lying or exaggerating. “No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality” This Scrum Guide quote applies not just how you will build it, it applies to figuring out what it will take. The product owner and the scrum master are supposed to trust the team and in turn, the team needs to be accountable to earn that trust. It’s not the scrum master’s job to call out a bogus estimate. Instead, it’s their job to create the space where the team feels safe enough to call out each other.

Technical skills are helpful, there is no question. However, the most important skills are those specific to being a scrum master, agile coach or consultant. If you don’t know your expertise, then having knowledge of the technology just means you can talk shop with them. You can’t fix their problem. So it’s not a question of “To be technical, or not to be technical?”. Instead the proper question is, “Do you have the skills to be right for the job you are doing?” Don’t assume you need something, just because you don’t have it.

CC0 Public Domain – PixHere.com

I looked in the mirror and was greeted with a satisfied smile. I looked good, today. My salmon shirt was nicely set off by the patterned eggplant and chambray tie paired with it. With the advent of summer, I was going with a pair of light charcoal slacks and the fresh shine on my Clark’s caught the lights above the mirror.

I’d certainly come a long way from my early twenties. There had been a time when I was let go from a temp office job because I kept showing up to work in the same handful of shirts, which were always wrinkled (I was young, an iron was a luxury then). Not that I really could take credit for my polished fashion sense. The only real credit I could take was having the good sense to marry my best friend and trust in her. I still remember the first time she handed me a salmon colored shirt.

“It’s PINK! I’m not wearing pink, that’s so Miami Vice.” Her reply was “It’s salmon, it goes with your eyes.” She’s always known me well, I’m vain about my eyes and so I capitulated and wore the “pink” shirt. I came home that day and told her that I’d gotten at least a half dozen compliments on the shirt, from men and women. That was pretty much that last time I seriously argued with her on fashion.

“You’re not going to wear that, are you?”, rumbled an all too familiar voice.

I rolled my eyes. Was I not even safe in my hotel room?  I shot a dagger-filled glance at the 800-pound gorilla now lounging on the sofa, “The sign on the door says ‘Do not disturb’, Hogarth.”

He waved the branch of a plant I recognized from the hotel’s lobby. Hoping I wasn’t going to get charged for that, I almost missed his reply. “Oh, that, I ignored it, we both know you’re already disturbed.”

Given I was talking to an invisible gorilla I couldn’t exactly argue with him. So I focused on what he’d clearly come to torment me on. “You can’t seriously think there is something wrong with my outfit, can you? You may be smart when it comes to people interaction but I am not going to take a gorilla’s fashion advice over that of my wife’s.”

Dropping the partially eaten branch Hogarth held both hands defensively. “Even I’m not that dumb. She could dress a chimpanzee up and get him on the cover of GQ.” Which given Hogarth’s opinion of his cousin species, was saying something. “Absolutely nothing wrong with the outfit itself. “, he continued. “I’m just wondering if you wanted this consulting gig to be extended past the initial 90 days?”

I stared at him, in disbelief “What? What has my outfit have to do with my consulting arrangement?”

“The customer is always right, right?”

I nodded.

“So why are you telling the CEO he’s wrong because he’s not wearing a tie?”

The CEO he was referring was my current client. He was a brilliant guy and he made Zuckerberg look like the king of high fashion. I looked back at my reflection and then back at Hogarth. “But what about ‘no judgment’? I’m an agile coach, I’m always promoting ‘no judgment’ in the workplace.”

Hogarth gave an enigmatic shrug,  “well you don’t want to end up like Prince Manfredi, do you?”

“Prince Manfredi?” I blurted while my mind raced to catch up. Renaissance history, really? Manfredi was the young prince of the Italian city of Faenza. One of the many Borgia princes conquered Faenza yet chose not to sack the town and even took Manfredi into his court, well at first. Manfredi would end up arrested and turning up very dead a year later. His crime was being better looking, more charismatic and nicer than the Borgian prince. So he was killed.

How was this relevant? I was about to rail at Hogarth for his complete non-sequitur when my brain caught up with things. Was he really quoting Greene?

“Never outshine the master?” I asked Hogarth.

He nodded.

When you shout “The Emperor Has No Clothes”, he’s likely to fire you.

Robert Greene wrote the 48 Laws of Power in 1998. It’s reportedly favorite reading of some of the more reviled CEOs in recent history. With laws such as “Pose as a friend, work as a spy” and “Play to people’s fantasies” it’s not exactly high agile reading.

Unfortunately, I’ve found a need to be passing familiar with these laws working as a coach, helping enterprises companies. One of the laws stands out as being unfortunately correct all too often. It is the first law, and it bit me more than once. It says, “Never outshine the master.”

No judgment is a great concept to teach your teams. As an agile coach, I do my best to teach and live by Brene Brown’s advice that “My life is better when I assume that people are doing their best..” Agile teams work best with open communication, honest dialogue and an assumption of positive intent.

The thing is, as a coach, I’m often working in companies that are still deep in the morass of such wonderful advice as “Use absence to increase respect and honor”. This means that while I believe in no judgment and in assuming the best from everyone, the people I’m helping may not be in the same place.

This means, that while I’m trying to help an organization move to more productivity, by enabling healthier teams, I have to always be mindful to how what I am doing is perceived by those I’m trying to help. This is a deeper issue than just how you dress. Whether or not you wear a tie just serves as a good perspective to approach this agile pitfall.

First, you need to understand that I love to wear ties. I enjoy dressing nicely. Polished leather shoes, nice shirts, the whole nine yards. I get a lot of enjoyment from dressing nicely. It’s part of my professional image and I’m proud of it.

And it probably lost me at least one engagement and made others uncomfortable before I realized that “no judgment” is something organizations have to work towards, not be instantly dropped into. In one engagement, the senior coach pulled me aside and told me I was making the sponsor self-conscious. Unlike some sponsors and bosses I’ve had, this sponsor actually dressed fairly nicely. The problem was, I dressed even better (again, all credit does go to my awesome wife, the salmon shirt story is 100% true). I was outshining our sponsor.

In other engagements, I’ve faced the challenge of the “grunge” engineering teams. When the best-dressed person on the team is the guy in blue jeans and a t-shirt with no holes, even wearing a button down shirt and slacks can be a major barrier.

The absolute irony, which I think in part stems from agile practices coming out of software engineering, is I’ve seen coaches show up to a client in shorts, t-shirt and flip-flops, sit in a conference room with a tie-wearing CEO and the CEO doesn’t blink an eye at the casualness. You see, it is far easier to overdress than it is to underdress in agile coaching. A contradiction I’ve been struggling with for years.

What people wear to work, and how they can feel threatened by what you wear, gives us an excellent view into the change challenge. As an agile coach, I’m an expert in dysfunctions. I can spot a half-dozen usually in the first five minutes of the pre-engagement call. Companies hire me to be that expert in dysfunction. They want me to come in and fix them. The same way that they are fine with you wearing whatever you want to the office, as long as it isn’t a suit and tie. While I’m hired to find and fix dysfunction, if I go about it like the child in the “Emperor’s New Clothes” I’m going to find that I’m not all that popular. Just like wearing a tailored shirt and tie can make them uncomfortable, so can pointing out their flaws in brutal honesty.

The worst sin is when you make the people you are trying to help look bad. I worked with one client where they had someone internally working as a coach. This person was a good-hearted person who, unfortunately, had learned agile with a stilted command and control perspective. In less than a month I was able to take two brand new teams and get them to a higher level of engagement and productivity than this coach had done with teams in more than six months. Instead of being thanked, I was shown the door because I undermined the full-time coach’s credibility with his organization.

Understand your audience, create trust, consult carefully:

What this all leads back to is how you engage with your client or employer in those first critical days and weeks. It is all about taking the time to form relationships and create those bonds of trust. The same thoughts I laid down in the AgileConnection article “Building Team Relationships as an Agile Coach.”

Someday I hope people can again wear ties without it being seen as some threat to what other’s wear. Until then, I relish the days I can wear my flashy ties and recognize the days when I can’t.

By Alan Chia (Lego Color Bricks) CC BY-SA 2.0

Download Simulation Here

“Useless, useless, useless!”

I flipped through the pile of classroom feedback for the millionth time. I was hoping that maybe this time I’d see something different. And like the last 999,999 times, the results were the same. I’m not sure why I kept punishing myself. Except that maybe by trying to find a different answer I could postpone trying to figure out how to fix the real problem.

I guess it could have been worse, heck a lot worse. I was getting really excellent scores and feedback, on the majority of my class, was universally positive and upbeat.

Except for my Scrum simulation. Arguably the core of my class, it was absolutely lacking in feedback, positive or otherwise. In dozens of feedback forms, when I asked the attendees to call out three things they liked, my Scrum simulation was never mentioned. If I was going to be a world-class agile instructor, I needed to get my core exercise out of the doldrums. Even negative feedback would have been helpful. Then at least I could work to address it. From first hand conversations about the best I was getting was “Meh, it tied things together all right.”

“Meh!… A lousy meh”

“Stirring praise, absolutely stirring!”

And my day just couldn’t get any worse. “Go away, Hogarth. This time you honestly can’t help me.”

Of course my gorilla ignored me and ambled over to my office’s small meeting table. “Oh, yeah, sure, sure. This instruction stuff is hard. All that making sure you cover all the points, keep them engage, ensure retention”. He set a small plastic tub on the table.  “I won’t bother you at all, just needed some place to assemble my LEGO Gorilla Escape, the Reckoning set.”

I almost let him suck me in, almost. I knew if I asked him any questions he would turn it into some deep dive into my psyche, examining how my brain was like a box of unsorted LEGO or something like that. Instead I went back to trying to solve my problem. How was I going to fix my Scrum simulation. Grabbing post-its I started doing some brainstorming.

Thirty minutes later I sat back with a disgusted sign. It was no use, my mind was blank. I was just hitting my head against a solid….

“Wall!” Hogarth said. Startled, I looked over at him. Using LEGO he had assembled a castle wall, complete with turrets and a parapet wide enough for a paperclip to march down like a toy soldier.

I rolled my eyes, “Hogarth, do you have to make something for everything I say?”

My gorilla was already building something new, an infinity symbol. “Well, it’s hard not to when these things are so versatile and not too mention fun. I mean you could do almost anything with them.”

Do almost anything…

Oh, of course.

Once again my gorilla had led me down the merry little path into the gaping maw of truth.

Who doesn’t love playing with Legos?

Lego Scrum Simulation for Enterprise is an interactive exercise for teaching the Scrum fundamentals. Useable either stand alone or as part of a larger class, students learn by doing. This ensures a much higher retention of knowledge than traditional lecture based question and answer instruction.

The simulation is heavily founded on Susan Bowman’s 4C training model. It seeks to get the students deep into the doing right away. In the course of the simulation they end up learning or reinforcing the majority of the Certified ScrumMaster course requirements. When included in an agile training class, it forms the Concrete 4C for the entire class, while itself walking through the 4Cs during the simulation.

Why LEGO?

An engineering director once told me “show me an engineer who doesn’t like playing with LEGO, and I’ll fire them.” While meant strictly in jest it does sum up “Why LEGO?” in an incredibly brief manner. I can count on one hand the number of adults I’ve met who when left alone with a pile of LEGO won’t start building something. They are incredibly tactile, highly engaging and the possibilities of combining bricks is effectively limitless (no really). They are also culturally universal. When I used the basic Scrum Simulation (based on the XP Game), I found students who didn’t have a clue how to blow up a balloon, or the first idea of where to start with folding paper hats. Rolling dice, something I grew up doing, is not second nature to everyone. LEGO, on the other hand, takes a second to learn and is as inviting as you can get.

What does “For Enterprise” mean?

As I went from learner to instructor of Scrum I learned how it fit with the students I taught. A vast majority of my employers and clients have been high-tech, software focused organizations. These organizations have many things in common, among them being a high-level of Technical Debt and an underlying set of dependencies that make building new technology often like a game of Pik-Up sticks.

As I crafted the LEGO simulation I wanted to address these issues as part of the simulation. Most of the simulations I’ve experienced were very focused on the basic Scrum mechanics, with an assumption on a single team doing all the work. By bringing in the concepts of Technical Debt and Dependencies, I gave my students a starting foundation for applying Scrum in their work.

Mechanics

The simulation leverages the well-used model of compressed sprints. During the course of the three-hour simulation the teams will go through four complete sprints, from refinement to demo. This includes tracking their progress on burn-up/burn-down charts and doing planning forecasting.

The concept of the simulation is that the team is building a city from LEGO. They are responsible for everything from the roads up and must plan their layout and deal with potential resource limits (there are only so many 1×2 45° Roof Tiles in your LEGO bin) along the way.

Story Cards are two sided, with the front including the title and story details. The front also has a business value assigned in dollars and an empty box for the team to put in their level of effort estimate. The reverse side has the acceptance criteria for the story.

Technical Debt is expressed via disaster cards. In a shameless borrow, from the SimCity game series, teams get a disaster card at the start of Sprints 2-4. Like any Technical Debt, they can choose to ignore it and suffer the monetary impact, or they can take time to fix it.

Dependencies are played out through the use of roads and intersections. Nearly every story requires it to be built on a road (commercial or residential) and roads are limited in length so require intersections to piece them together. There are also acceptance criteria that dictate how far apart some buildings must be, which in turn drives the need for more roads.  When the product owner is proposing stories to the team, the team has to look at the criteria and let the PO know if a road or intersection will be required. Sad is the team that builds a perfect University and then forgets to put it on an appropriate road.

Available Creative Commons:

All my material is available for download on my Resources Page. It is shared under Creative Commons Attribution-ShareAlike 4.0 (CC BY-SA  4.0). I ask that you credit me if you use the materials and if you make modifications to the simulation, those modifications are not monetized.

I would love to get any feedback on your use of the simulation. It will help me to continue to improve and expand the simulation.

I will continue to expand this simulation, over time. I felt, though, that it was high-time I put it out for general consumption.  I realized, that after sitting on this for over a year,  I was falling into the “has to be perfect” trap of writers and not following the principles of “get it out, get feedback” of agile. For example I am releasing the Facilitator Guide without complete facilitation notes.

Go, have fun and create many awesome agile learning moments with LEGO!

Variations

Scaling: Probably the most commonly asked question I get is, “what about where all the teams are building to a common map?”. This request comes from the desire to see how teams would scale working on the same code base. I absolutely love this concept and once I sort out individual team model more, I intend to look into a Scaled Lego Scrum Sim.

Pre-Built: I’ve demonstrated the simulation at over a half-dozen conferences and meetups. With a short time format, I can’t run through the entire simulation. What I do is start the teams with a blank map scape for Sprint 1 and then skip them to Sprint 4. I pre-build Sprints 2 and 3 and hand these out after Sprint 1. I also give them sprint data for the two middle sprints, so they can update their information radiators. This allows people to experience the full extent of the simulation in a short time period. In the future I may explore this as more than just a demonstration and possibly a way to deliver the module faster.

Credits and Attributions:

The Lego Enterprise Scrum Simulation is based on the Scrum Simulation by Agile Learning Labs (AgileLearningLabs.com), which is in turn based on the XP Game created by Vera Peeters and Pascal Van Cauwenberghe (http://www.xp.be/xpgame.html/). It also draws inspiration from the Lego Scrum Simulation by Alexey Krivisky (http://www.lego4scrum.com).

My world was running like a well-oiled machine.

I looked over my dashboards, flipping through tabs with a gleeful joy as I saw everything in its proper place. We had ten teams running good and proper Scrum by the Book™. All the standups were in a neat little cascade every morning, allowing myself and management to go from standup to standup like doctors making their morning rounds. Everything was being tracked and we had metrics for every little aspect of the project and product. I was seconds away from instant knowledge of any project we were working on.

All in all our transformation to agile was going supremely well. I couldn’t be happier.

“What’s that line there going down?”

Okay, I’d be happier if I didn’t have an 800 pound, invisible gorilla as a conscience.

I turned to face my gorilla. “Hogarth, it won’t work this time. Everything is going brilliantly.” I waved at the dashboards, “see, on time, on budget, etc. etc.”

The hulking form of Hogarth leaned over my shoulder and looked at my monitors for a few moments. Finally, he shrugged and looked at me. “For now…”

I goggled at him, “Can’t you ever be happy? Quit borrowing trouble from the future.”

Hogarth waved at my screens, “speaking of happy, isn’t the team happiness going down across the board?”

I grumbled to myself. A dozen metrics and he picks the only one that doesn’t look good. “Hogarth, we’re shipping more stuff than ever and it’s higher quality. More importantly, the agile transformation is a textbook rollout and working by the book™.

“So process is more important than people? I thought agile was the other way around?”

I blinked. Blinked again. Looked at Hogarth. Looked back at my screens.

“Umm…”

Healthy beats “agile” any day

In 2010 I started working for the Branded Products Group of Hitachi GST (now part of Western Digital). This group was responsible for taking the world-class Hitachi hard drives and putting them into consumer grade products. Or as I liked to say, “We’re building the kind of stuff you’d see on a shelf at Best Buy.” I was brought in to set up and run a program management office with a goal of establishing some predictable product release schedules. Hitachi itself had a massive Six Sigma, multi-year lead time, product lifecycle. Whereas the Branded Group was a recent acquisition that still was operating in what I call the Startup Chaos Lifecycle.

It was my first experience with consciously implementing agile practices and I have proudly held it up as an agile transformation example in the years since. When you look at the raw numbers you certainly can’t argue my efforts were successful. When I joined the company Branded was struggling to ship four projects a quarter. When I left, less than eighteen months later, the group was on track to ship over thirty projects in the quarter. A highly successful benchmark.

The question is, was it agile?

I wasn’t running Scrum or Kanban for the projects. Even in the small software team, our attempts at Scrum were highly questionable. We had weekly status meetings, not daily standups. We planned projects in an upfront planning cycle and stuck to them often despite reality telling us to stop. Our teams were operationally siloed instead of cross-functional. Almost everything you think of as “classically” agile was probably not being done. The transformation was certainly not Scrum, not Kanban and possibly not even Lean.

So was the organization agile?

Who cares…

It was healthy, it was producing rock-solid products, it was producing more per quarter than ever before and the teams had the best morale they’d ever experienced.

I absolutely believe that Scrum(XP), Kanban (and the new models emerging from both) are some of the best ways to develop products. And at the same time, I recognize that sometimes the organization is not going to be ready, able or willing to move to these agile frameworks.

Organizations, however, are ready to focus on healthy projects. Faster communication cycles will let us know if we’re off course earlier. Closer communication with the customer means we know if we are really delivering them the value they care about. Being flexible in our planning, instead of blindly marching off the cliff when we see the “Bridge Out” sign. If the organization is still writing big, upfront design documents or shipping on a yearly cadence, that’s fine, so long as they are putting a focus on the health of the project and teams.

And really, that’s what big letter Agile is about. It’s four values and twelve principles that tell us how we should work together on the delivery of a product. I’m constantly inspired by something Dr. Kevin Thompson said, in a Waterfall vs Agile panel many years ago. He was challenged that you “wouldn’t build a nuclear reactor using Scrum, would you?”. Kevin responded with “No, I wouldn’t use Scrum. I would, however, use the values and principles of agile in running the project.”

Having healthy projects is more important than the specific frameworks or methods we use. And following the values and principles of agile, even in a “waterfall” project is going to lead to healthier teams and more success.

Source: WikiCommons

“So I’ve had a great idea.” Mr. Huggle wandered into my office on one of his unannounced visits. He had a magazine rolled up in his hand and was using it like an orchestration baton. “We’re going to go agile so we can be faster!” he announced triumphantly.

Oh dear Snowbird, he’d read another article in CIOs-R-Us magazine. On the one hand my heart had skipped a beat at the mention of agile. Might I finally be able to bring my Agile PMO out of the shadows and really effect a proper transformation? On the other hand, he’d used the “go faster” catch phrase. The article he’d read was probably written by some big five consulting firm who knew as much about agile as I did about astrophysics (less than none).

“That’s great, boss.” I began tentatively. “But I’m not sure that’s the actual goal of agile, though. If you read the manifesto…”

Huggle waved dismissively. “Manifesto? This isn’t some revolutionary movement. It’s a business process implementation. The guys at McLoiterson explained away that who-ha right away.” He waved at the rolled up magazine. “I’m going to get on the phone with their sales people today and see about getting some help in for us.”

He got up and started leaving my office. Pausing he turned around to ask “Say, you know something about this agile stuff already, right?”

I nodded, mutely.

“Great, why don’t you come up with an initial plan for how we can go faster first. No reason to pay pricey consultants if we can do it ourselves.”

And with that, he was gone.

I buried my head in my hands. It was my fondest dream and my worst nightmare all at the same time. How in the world was I going to convince Mr. Huggle that agile was about so much more than speed? That is was actually not about speed at all?

“No buts about it, and time to get to work,” said a voice from the dark corners of my office. Hogarth always managed to be elsewhere when Huggle came by. But clearly, he had been close enough to hear the conversation.

I looked up as the imposing shape of my personal gorilla loomed out of the darkness. “No buts? I thought you told me to never use that word?”

Hogarth flashed a brilliant smile, “Precisely…”

The Manifesto Doesn’t use the word Fast Even Once!

Like a bad penny, the “Agile lets us go faster” meme pops up again and again. The concept that we will go faster if we just adopt this agile thing is naturally enticing, so it’s not surprising to see it constantly coming back up. What managers or executive doesn’t want the lure of shipping their products faster?

Now, If we were just facing hopeful leadership we could tackle this in the normal manner. Unfortunately, I’ve started seeing this pop up in the words and writings of some notable voices in circles of better business, better development, and agility. No, I’m not going to call any of it out specifically. In retrospective it’s not about who did it, it’s about what can we do better next time?

So let’s do that. What can we do about this trend? How do we address the reality, that no matter what we seem to do, the conversation always comes back to “agile makes us faster, right?”.

“Yes, And”

The trains already left the station, folks. We are not going to separate “Agile” from the perception that it’s about “Going Faster” or “Shipping Faster”, or any other implications of agile and speed. That ship has already sailed and we are not going to get that horse back in the barn, so there is no use crying over spilled milk.

So let’s stop trying and instead focus on the power word “and”. Back in 2012, I wrote “The Agreeable Gorilla: The Power of And.” In this blog, I go on at length about the improvisation exercise of using “Yes, and.” More importantly, I caution against using “But” in pretty much any conversation.

That’s what I come back to again for this conundrum. We won’t change minds, especially if we keep insisting “But agile isn’t about going faster, it’s about…” Pretty much people tune out right after the “But agile…” part.

So instead let’s try some of these things…

“Yes, and in order to realize that speed you need to focus on making strong teams.”

“Yes, and we need to set up your systems so they can support that speed.”

“Yes, and if we get the coding faster, without improving how we test, we won’t be able to release any faster.”

We all know that you can go faster with agile. Sure, faster is not always what you need to be doing. And sometimes it is far better to go with the popular flow and use the enthusiasm of the “going faster” people to channel the organization towards healthy and sustainable agile.

Source: Wikimedia Commons

“I don’t understand, it was a textbook implementation! I should have been able to do it with my eyes closed. ”

For once, I was talking to my gorilla willingly. Well not so much willingly. It was more I had no choice since the only other “person” in my home office was Hogarth. Of course, Hogarth didn’t seem to be listening. He was more intent on the garden just outside my window. I could almost see him cataloging the various plants. The long and hungry look he gave the ancient wisteria was troublesome.

Oblivious to this, I continued my rant. “I did exactly what they asked for, I executed letter perfect to the book. We had scrum rolled out to all twenty teams in record time. Heck, you couldn’t walk ten feet in their office without running into an information radiator.” Noticing Hogarth was not paying attention,  I turned to glare at him. “You’re not helping me at all!”

Hogarth reluctantly tore his gaze away from the garden view. “Why do you need me, like you said it was a textbook roll out. What do you think caused the failure?”

“What do I think?…” I stared at him open-mouthed. “If I knew I wouldn’t be talking to you now would I?”

Hogarth just kept looking at me.

“Fine!” I threw up my hands. “Let’s see. The first problem I noticed was the timebox kept getting broken.” I waved my hand at Hogarth, “That wasn’t it though, they actually had existing SLAs and agreements in place that supported interrupting the teams.”

“Existing processes you say?” said Hogarth. “How might you have learned about them?”

“I did learn about them!” I grumbled. “I just didn’t learn soon enough.”

Hogarth nodded. “Uh huh… Tell me what was it you wanted me to do again?”

Was he serious? “Damn it, Hogarth, I want you to listen to me. Just listen, don’t try and fix the problem. Don’t be the damned expert, just listen so I can work this out…”

My words trailed off to nothing. Hogarth had done it to me again.

You have to be agile to be successful in agile

Note: This blog is based on the article I had published on AgileConnections.com in January of this year. 

The problem with the classic playbook model is it follows a fairly standard set of steps. Sure, you might alter the timing a little, the overall process though is pretty much set down. No, it’s not as bad as that call center script the agent used on you last week. However, it can still lead to pretty upset customers as you try and roll out something that doesn’t work for them. “But I was just following the plan” isn’t going to save your engagement.

Even reaching all the way back into my project management days, I realize that I understood this unconsciously and managed to suppress that unconscious knowledge time and again in order to “follow the process” like I had been trained to do.

Perhaps it was my background in 1990’s era computer game technical support, where every customer’s problem was just a little different or just plain common sense that drove that not listened to, subconscious realization. It would take a decade of project management and a good five years of agile coaching before I came to the conscious understanding that it wasn’t the process, it was the ingredients.

Think of each customer like an episode of Iron Chef (America or the original Japan). Your judges (customers) are different every time. The live audience (additional stakeholders) will have a different energy. The secret ingredient (unique challenge) is always different. And your sous chefs (team) might even change from challenge to challenge.
What is almost always a constant though, is your pantry (tools) and basic kitchen appliances (core process frameworks). Having a strong mastery of these cooking basics allows you to assemble ingredients in unique ways and cook them to meet the needs of the customer.

What are my “Go To” ingredients and kitchen appliances, we all have them? Bobby Flay is going to reach for BBQ of some kind. If Michael Symon doesn’t use bacon at least once we think he’s ill and Mario Batali was sure to reach for some kind of pasta. You could also count on the blast chiller and ovens getting used in every episode.

So what do I always reach for?

Three ingredients and two appliances.

Three “Go To” Ingredients

Organization-wide education

Education is a key to any transition. I’ve learned that education normally needs to happen early, and it needs to be organization-wide for it to be most effective. If teams are trained differently on what agile means, it can lead to what essentially amounts to language barriers. Educating everyone at once leads to shared understanding and support. You can read my Agile Connections article for more on my Education First recommendations.

Observation phase

The principle here is “Do no harm.” When you first start an agile transformation, be it as a new hire or in a new project, you are almost always an outsider. You need to build trust before you can make a difference. The best way I’ve found to build relationships and trust is through asking questions and listening. Until you understand, you can not help guide change. I delve more into building team relationships in this Agile Connections article.

Engagement phase

This phase is what most people think of when they think of an agile transformation: the agile coach rolling up his sleeves and diving in to help individual teams. Doing hands-on facilitating with one-on-one coaching is a vital part of a transformation.

My key component for a successful agile transformation is to focus on one thing at a time. After engaging with the team, it’s typical to come away with a dozen observations as well as the team’s own reflections from their retrospectives. When faced with a huge list of things that can be “improved,” it can be very easy to start tackling it all, but you should fight that urge.

In agile, we coach teams to focus on one user story at a time, and it’s no different for improvements, impediments, and blockers. Start a team backlog for things the team wants to improve. Have them pick only one thing to work on at a time, and when they reach that goal, move the “story” down the backlog.

Two Key Appliances

Inspect and adapt cycle

One of the most underused agile tools is the retrospective. We tend to limit retrospectives to the team level, focusing only on the previous sprint. If you replace the tires on your car and ignore all other maintenance, it won’t matter how great those tires are—eventually, the car will stop running.

Retrospectives need to move beyond the team to the entire organization. You must apply the principles of continuous improvement to all levels of the organization on a constant basis.

And remember, inspect and adapt are two separate steps. We can be really great at finding problems, then do poorly on fixing them. Without the follow-through, inspection is pointless. You need to create an organization-level impediment backlog that is tracked and managed by the leadership team.

Assessment & Self-Supporting Metrics

People in any organization have a driving need to know how they are doing. In the case of an agile transformation, we always want to know two things: When will we be done, and is this agile thing working? To this end, metrics provide a vital service to the health and well-being of an organization and some kind of organizational assessment tool tells us if the transformation itself is being successful (You can be shipping tons of new value and still be failing).

With metrics, as I advocated in my previous blog, “Metrics: The third rail of agile adoption” you need to have interlocking metrics so you don’t fall afoul of Goodhart’s Law and have the teams gaming the system to satisfy leadership’s desire for some imposed goal. Using metrics responsibly is also vital. I give detailed advice on the responsible use of metrics in this article.

For organizational assessment, be consistent. If you measure one car in miles per gallon and the other in feet per second, you just end up confusing things. A common set of assessment tools allows everyone to track to the same understanding. I delve more into how to pick a good assessment strategy in this Agile Connections article.

The Cookbook doesn’t care about Frameworks

One thing I want to make sure to call out. Everything written here is totally agnostic of what frameworks or methodologies you are putting in place. Whether you are using Scrum or Kanban, SAFe or LESS, or whatever my go to things don’t change. Think of these frameworks and methodologies like the set of an Iron Chef. I don’t care if I’m in LA or New York, inside or outside. At the end of the day, I’m still going to reach for the same core ingredients and tools to roll out whatever agile framework is best for the customer.

Am I an Iron Agilist?

Okay, I have my “go to” ingredients and appliances, so what?  Plenty of challengers have faced the Iron Chefs with a “go to” approach and failed.  Am I winning any Iron Agiist competitions?

Well in one of my most recent agile transformations I have close to two years of data showing the before and after of their agile transformation. In a twenty team transformation, the overwhelming majority of teams saw thirty percent or more improvement in predictability, reduction in cycle time, and increase in velocity. They all also saw strong improvements in organizational maturity and happiness.

The biggest change always happened after education. After a team had gone through one of my two-day training, they always saw a marked improvement in their metrics.

Oh, one last thing. You know how every Iron Chef tries to use the Ice Cream maker and it almost always fails (trout ice cream anyone?). Be on the lookout for your agile ice cream maker. For the longest time, my ice cream maker was the C-Suite. I had to learn how to work with them to advance as an iron agilist.

Hint, the answer is yes…

“Arrrrgghhhh” I let my head fall to my desk with a resounding thud.  I let the momentum of the bounce  carry my head down again, and again, and again. Honestly I’m surprised my desk hasn’t broken with the number of times my head and it have come into repeated and violent contact.

I honestly don’t know how Don Quixote was able to tilt at all those windmills. After months of tilting at windmills I was utterly wiped out. It seemed every time I made a little progress, something would come along and drag me back into the quagmire of command and control  planning cycles.

“How on earth am I supposed to engineer an agile transformation when  no one in the organization even knows what agile is?” I muttered into the darkness of my office.

“That’s your problem” came a reply from out of that darkness.

I sighed. Just what I needed, as if trying to swim against the tide of anti-agile wasn’t enough, now I had to deal with my 800-pound gorilla conscience telling me just what I did wrong.

Looming out of the darkness, I could just make out Hogarth’s outline. “What now, Hogarth? Can’t you see I’m busy denting my desk?”

He gave a nod as he settled onto the edge of my desk. The desk gave a groan of protest, which Hogarth ignored instead producing a branch of bamboo from somewhere. The only bamboo I knew of in the office was in the CEO’s office and I cringed to think of what worse could happen to me if the CEO found out my gorilla ate his plant. “Relax” he said, waving the bamboo at me. “Bamboo plants over-night from Amazon prime.” He pointed at the spot where my head had been impacting the desk, “so problems with the agile transformation again?”

I leaned back with a sigh, “Yes,” I rubbed my face, “they know they want to go agile, but they haven’t the first clue what it is and every time I try and suggest something I get pigeonholed back into my little box. I can’t make any progress because they haven’t even gotten started. Resistance to change is high. I don’t know what to do.”

Hogarth shrugged, “not much now. It’s what should have been done before you even got here.”

I looked at him confused, “Huh?”

“Before you can pave the road, the path must first be found.”

I glared at my gorilla. He had a knack for pulling just the right quote from history to make his point and I’d been burned enough times by this that I was learning to ask before snapping. “Okay, who said that?”

“I did,” Hogarth said with a certain amount of smugness.

I blinked. He’d done it to me again. Just when I thought I had this whole invisible, conscience gorilla thing figured out he’d done it again. Then I stopped and blinked again. Realization dawned on me. He’d done it twice.

“The path must be found…” I muttered.

Should I hire an Agile Contractor, Agile Consultant, or Agile FTE Coach?

In my last blog, “To FTE or not to FTE” I looked at the Consultant, Contractor, FTE question from the point of view of the Agile Coach. Here I want to discuss it from the hiring company’s perspective. What are the pros and cons of hiring different types of agile coaches?

Full Time Agile Coach: A paid employee of the company, the Full Time Agile Coach is in for the long-haul. They are directly invested in the long-term well being of the company, often in the extremely measurable form of stocks and options. While still relatively uncommon, there are several notable companies using full-time coaches to help their scrum masters and scrum teams. As I write this I’m working  for AOL as one of four internal coaches. Salesforce.com has a large agile coach team to support its 1500 plus scrum teams. Other companies I know that have used full-time coaches at some point are Twitter, Lending Club, Fit Bit and General Electric.

Benefits of hiring a Full-Time Coach:  It is an oft stated truism that you are never truly done with an agile transformation. It’s an ongoing journey that never ends. And if your journey is never truly over, having a full-time coach means you have someone helping you no matter when or where you are in your journey. Think of it this way, when the Denver Broncos won the Superbowl, in Feb 2016, did they say “Oh we’re the best now, we don’t need our coaches anymore?” Not likely, while sports team coaching staff may change, what doesn’t change is the need for them. Having the full-time coach means you always have access to this critical resource. Something else you gain is organizational knowledge. There is only so much you can learn about a company in the common 30-90 day consulting arrangement. Your full time coach knows the people, the process, the history and where all the minefields are. They don’t have to “come up to speed” and have plenty of time to build strong relationships.

Downsides of hiring a Full-Time Coach:  The downside to a Full-Time coach is that being part of the system impacts their ability to effect large-scale change. Unless your agile coach is a vice-president or higher role, with a big army of directs, they rarely have the positional / role authority to make changes. This leaves them working from within the system on their influence power. This can slow down change and if you are just starting out, can make it very hard on the coach and the company. Often to the point of the transformations failing and the coach looking for a new job. When this happens, it is not usually not the coaches fault.

Consultant Agile Coach: The hired guns of the business world. The have deep expertise and a broad background of knowledge gleaned from many clients and past jobs. The consultant’s job is to come in, solve the problem and then ride off into the sunset while you murmur “who was that masked coach?”.

Benefits to hiring an Agile Consultant: They are the expert. You hire them because they have a deep well of knowledge on your problem. They know how to fix pretty much any problem you may have and thanks to the “hired gun” aura, they can actually get the problems fixed. Even the lowest tier consultant carries the authority equal to a director (a manager of managers) and often has the aura of authority to go all the way up to the CEO and direct what should be done. When you need something done and done fast, hiring a consultant is often the most expedient solution.

Downside of hiring an Agile Consultant: Eventually your hero-for-hire is going to leave. And that is usually a fixed schedule event. It’s the rare consultant who stays until the work is done (scope driven). So just like your average product release, they have a fixed schedule and way more features than they can ever hope to deliver. This requires the consultant to work fast to get everything done. And like in software, when you work under a pressure deadline, they will often end up sacrificing quality or documentation. When the consultant rides off into the sunset your implementation may be incomplete, have undetected flaws, still have organizational resistance or lack the education hand-off needed to sustain the change. I know of many agile transformations that were initial successes and then slid back into their old waterfall ways because they lacked a sustaining force.

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

The independent consultant is a sole proprietor business, sometimes with a support staff and sometimes not. They can also range from the small name shop up to a “named” agile thought leader. When you hire an independent you know you have their attention. If you hire one of the “names” you also get their specific expertise, which is often what everyone else bases their work on (If you hire Jeff Sutherland, you know you’ve got the expert on Scrum theory). However the Indie is also always going to be partially unfocused. They always have to be sourcing their next client. Even with a support staff, you often need the consultant to make sales calls to close deals. For the smaller independents, they can be a great choice for a small company getting started.

Hiring a “Firm” means you are often getting the combined knowledge of the whole organization. Even if only one coach shows up, that coach has the backing of their firm and can tap into the tribal knowledge.  Three of the most notable firms that fall into this category are SolutionsIQ, Leading Agile, LeanDog and Thoughtworks. Other Firms are more like a talent scout, finding really good independent talent and connecting them with the best fit. cPrime and Agile Transformations are a great example of this type as they work with many independent coaches, while also having an internal practice org that supports them.  Hiring a Firm comes with a lot of benefits on the engagement, however they can often be more expensive than the small indie coach. Though likely less expensive than one of the “named” independents.

Contractor Agile Coach: The hourly agile coach. Like the brilliant coffee aficionado, working behind the Starbucks counter, their knowledge and skills are often not seen or used because of the perception they are just a “temp” or the “hired help”.  Added to all the other issues, contractors have plenty of rules around them so that they never really one of your employees and rarely have support from a parent company like a consultant.

Benefits to hiring an Agile Coach Contractor: There isn’t. Companies that hire contractor coaches are losing out on nearly all the benefits of either the FTE or the Consultant. The only real value comes in the lower costs and being able to source them from contract firms (there are several that either specialize in agile or do a lot of agile business). However, you get what you pay for. While scrum masters as contractors works out okay, coaches as contractors is bad for the coach, bad for the business and I’m not aware of any successfully sustained successful transformations with a contractor coach.

Downside of hiring an Agile Coach Contractor: You get what you paid for. Contractors are usually considered “Staff Augmentation.” This puts them into the org structure like an FTE, only they generally end up at the bottom of the social and role power pecking order. Coaches need to have stability or authority to operate and get neither as a contractor. As Nancy Reagan used to say “Just say no.”

So… (Conclusion)

Let’s get the hard and fast out of the way. Never hire an agile coach as a contractor. While this is an excellent tactic for a Scrum Master, for an agile coach you are getting none of the benefits and all the of downsides possible. It may save you money and it may be easy. And you will get exactly what you pay for. Every company I’ve heard of, that tried to use contractor coaches to work an agile transformation, has not only failed to make any real change, they have burned through multiple coaches and gotten  a poor reputation in the agile community.

So then, Consultant or FTE Coach? 

Both…

My belief and recommendation is that for a successful agile transformation to take hold in an enterprise company, one must take a little from column A and a little from column B.

Start by hiring a good enterprise-class agile consulting company. Bring them in to help you find your path and get you on it. They will have the ability to overcome the institutional inertia and get the transformation rolling. Part of their transformation work though is to set you up for success once they have left. Before they leave they need to help you raise up an internal resource or bring in an external resource to carry on as your full-time coach.

The full-time coach (or coaches) will then carry forward using the inertia of the agile consulting firm. They will keep the transformation on the rails and act as the guides whenever things start to get lost.

By combining the authority change-agent power of the consultant, with the stable expertise of the full-time coach, you will greatly enhance the chances you will be successful in the long run.

“Seriously?!” I was dumbstruck. How did this happen?

What I was looking at was nothing short than a monumental divergence of goals. The VP over the product group wanted to open up small satellite offices in several locations across the US. Granted, each location would be fully connected, high end telepresence rooms, live work space cameras all backed by a top-end online agile management tool. On the face of it, not the worst implementation for a distributed workforce using an agile development model. 

Only it was in direct contrast to what Jake had been working towards. He’d been working with facilities and they had a plan all in place to gut the development floor and rebuild it as a fully integrated team workspace. Pods for each team, quiet spaces, team dedicated meeting rooms with floor to ceiling white boards, the works. The perfect co-location workspace. 

Two wildly divergent plans. Yeah, they both were completely supportive of the company’s move to agile. The problem was they were pretty much diametrically opposite approaches.

“How on earth did I get here?” 

“Well, you got in your car this morning, got on the 280, headed south…” 

I looked up from my computer display to my unwanted visitor. Hogarth, my 800 pound imaginary gorilla and self-appointed conscience was leaning against the door to my office. He’d already reached over and stripped a branch from my latest fichus tree and was carefully plucking a leaf from it (Someday I’d figure out how an imaginary gorilla managed to cost me a fortune in real plants). 

“Hogarth, I’m not in the mood for your beat around the bush word games. If you have something to say, just spit it out.” In retrospect, telling a gorilla, imaginary or not, to spit probably wasn’t the best choice of words. 

Fortunately Hogarth didn’t take me up on the format of communication. Instead he quietly snacked on the fichus branch for a minute. “Well,” he said as he tossed the denuded branch to the side, “sounds to me like an alignment issue. The teams and management don’t have the same view on the why. The same order of values.” 

I gaped at him as if he’d suddenly grown a second head and it was speaking in Latin. “Look, everyone from the CEO down to the front line coders can recite the agile values and if they don’t know the principles by heart, we’ve got them on posters around the whole office.” I pointed to an example of such on the wall of my office. “So we are plenty aligned on what agile means.” 

Hogarth looked at the poster of the agile principles and cocked his head to the side, “Which one’s first?” 

I shook my head forcefully. “Are you crazy? They are all equally important. The Manifesto drafters didn’t number them.” 

“Oh, so they are all a P0 feature, I get it now.” Hogarth nodded with a satisfied smile. 

“Wait? What!?… No… I mean… Umm….” 

I really hate it when he does that.

The Agile Principles, they can’t all be Priority Zero

How many of you have seen a classic Product Requirements Document (PRD, MRD) where the majority of the feature requests are priority zero or one? Yep, me too. It’s the job of one of twelve principles of agile “maximizing the work not done” to address just this problem. It’s part of what drives the creation of a rank ordered backlog. The backlog is one of the overarching “artifacts” of agile (and lean). You can be running sprints, doing Kanban pull, DAD, SAFe, LeSS, XP, etc and you will have a backlog. Few if any other “artifacts” have that kind of span.

And yet, we’re expected to hold all four agile values and twelve agile principles as equal?

Okay, yes, that would be awesome. A truly transcendent self-organized working group that has moved beyond the material concerns of today’s world.

Reality though tends to point out that having more than one priority is nearly impossible. Peter Drucker said something to the effect of “an effective executive can focus on one thing really well. An exceptional executive can focus on two.”

We rank order our product backlog. We even rank order things coming out of our retrospectives. And yet we don’t spend time aligning on the principles of agile? We can’t do twelve things at once, so what do we focus on first?

Agile Principles 20 / 20 Exercise

This simple exercise can quickly let a team, of up to twenty, rank order the agile principles from highest priority to high priority (recognizing that all the principles are important). By conducting the exercise across the company, you can quickly get a sense of priorities and where alignment is lacking. For example, I’ve found development teams often put “welcome changing requirements” very low on their list, while a product management or sales team might place this very high.

Understanding where alignment is lacking, will then allow the conversation to bring about that alignment. At the end of the day, Sales could end up realizing that development’s goal of “delivery working software frequently” is better than getting to make changes weekly. You have to have the knowledge, to have the conversation, to gain the alignment.

Exercise In a Nutshell: The exercise in two hundred words or less (152 to be precise).

Print each principle on a single sheet of paper. Find a bare piece of wall. A neutral facilitator then randomly shuffles the cards, placing “Our highest Priority” principle at the bottom of the deck. The facilitator places the first random principle on the wall and invites discussion. Then the second principle is held up and the team is invited to decide if it is more or less important than the first. This proceeds through eleven principles, with discussion as each one is placed (trust me, there will be a lot as more cards get on the wall).

When you get to “Our Highest Priority” explain that while the signers of the manifesto did not rank order the principles in general, they did put this one at the top of the list on purpose, feeling it to be the most important of equals. Challenge the team on if they feel it is also the most important.

For a complete walk through of the exercise, you can download it from my Dropbox share: Agile Principles 20 /20 Exercise.

I’ve also created a Pecha Kucha format presentation, which I’ve shared on Slideshare , under the name “Agile Principles 20-20 The Gorilla Coach”

Credit where credit is due. I learned this technique from the dual powerhouses of Jason Tanner (@JasonBTanner) and Luke Hohmann (@lukehohmann). Jason is a Certified Scrum Trainer and CEO at Applied Frameworks, a company that specializes in helping your company get its product direction and strategy going in the right direction. Luke is the founder and CEO of Conteneo Inc., well known for their Innovation Games which is now part of their larger Collaboration Cloud. I took a Certified Scrum Product Owner class co-taught by these two gentlemen and learned this exercise in their class, which uses Conteneo’s 20/20 collaboration game as a the framework.

Photo by Danilo Rizzuti

“I just don’t get it.” I was staring at the email thread on my screen. I was in utter disbelief as to what it was telling me. Like pulling on a single loose thread unravels a cartoon sweater, this one email thread had just unraveled three months of my hard work on the Jericho project. I felt like the walls were falling in on me and a part of me was hoping the building would collapse and crush me so I didn’t have to deal with the fallout.

Turning in my seat I stared out my window taking in the inky black of a moonless night. Jake’s email had started the thread innocently enough. He wanted to make sure we’d addressed the dependency with the data team before he started work. Donald’s reply pointed to a dependency with the release operations team and capabilities of that datacenter. This led to a ever growing cascade of dependency and communication issues that were culminating in a pretty simple message, the project was dead before it ever laid the first brick of its foundation.

“I just don’t understand”, I said to my reflection, in the window. “We planned everything, we reviewed the plan, we had buy in. What went wrong?”

A voice answered me from  the darkness of my office, “I believe the technical term is that the right hand didn’t know what the left hand was doing.”

Why did I ask a question? Didn’t I know exactly what would happen if I asked  rhetorical question?

“Of course you knew what would happen,” replied my 800 pound conscience. Hogarth reached his massive hand out of the darkens to turn on my desk side lamp. My office no longer lit by just my computer screen, I could clearly see Hogarth looming from the darkness of the rest of my office. Flashing me a blindingly white smile, he continued “Don’t feel bad, you know I would have answered even if you hadn’t talked out loud.”

I sighed. He was right of course. May as well just take the medicine and hope to get it over with. “Enlighten me, oh wise one.”

My gorilla wagged a baguette sized finger at me, “Now, now, I’m the sarcastic one here.” His other hand came into view with part of my fichus clutched in it. Nibbling on some leaves he said, “your problem is you didn’t tie off with your stakeholders right.”

“Seriously?!” I just stared at him. I had most definitely met with my key stakeholders. Heck, half of them I met before the project even started.

“Having coffee with Jake doesn’t count as meeting your stakeholder.” Hogarth scolded.

“Don’t start, Hogarth. I know how to talk with my stakeholders. I have relationships with all the key ones.”

He nodded his beach ball sized head. “Yes, you do. Let me ask you a question though. When the teams create user stories, is there a specific formula?”

I nodded.

“And when you do release planning, is there an agenda and set of questions you always ask?”

I nodded.

“And yet your meetings with the stakeholders are informal, not structured and not the same. How do you expect to know if  they are on the same page if you don’t ask them the same questions.”

Huh…

Ask the Same Questions, you will see Patterns

The Internal Customer Interview has been a staple tool in my project tool box for years. I first adapted it from Manager-Tools.com and over the years have  tweaked it and discovered its value beyond just when starting  a new job.

Now stakeholder meetings are nothing new. Even the Hogarth me knew to have meetings with the stakeholders. The secret to why the ICI tool works over standard relationship building meetings is in its consistency. If you don’t have consistency across your reviews, you’re not getting proper value out of your interviews.

Say you meet with ten stakeholders and with each of them you have a different agenda and questions, then you only gain the context of that stakeholder in that stakeholder’s domain.  You are less likely to pick up on trends that crossing the organization.

With the ICI format the key is to ask the exact same questions to each stakeholder. By asking the same questions, you can take the qualitative data of a single interview and begin to form a quantitative view of the whole through repeated asking of the same questions.

An interview shouldn’t be more than 30 minutes, so generally you want to limit yourself to five or six questions.

The Questions:

New Job / Major New Project:

These six questions are what I used when would start a new PMO job or major new PMO project.

1‐ What do you and your org need and expect from the PMO team?

2‐ What metrics do you use to assess us?

3‐ How have we done relative to your needs?

4‐ What’s your perception of our org in general, that perhaps the numbers don’t show?

5‐ What feedback and/or guidance do you have for me/my role/my team?

6- What are your biggest pain points?

Agile Stakeholders:

I developed these questions working for LeadingAgile. They are designed to evaluate where company is with its agile transformation (or preparing for an agile transformation). It extends beyond the recommended number of questions because of the sub-questions. It still fits into 30 minutes though, since the follow-up questions are generally shorter answers, so it still fits the model.

1- How well do you think <your company> is doing at establishing long-term, executable product vision?

2- How well do you think <your company> is doing at release planning (next 3 months) and making this plan transparent?

   2a- How well are you doing at meeting the commitments in the planned work?

   2b- Was new work added to the release plan after planning close and if yes, what percentage of overall backlog changed?

   2c- If yes to 2b, what percentage of new work was from farther down the existing backlog as opposed to brand new features/stories that did not exist when release planning closed

3- How well are you doing at delivering of working, “accepted” product to the end customer? Is it high quality, is it delivering value to the customer?

4- How well do you think <your company> recognizes problems and opportunities for improvement? With it’s Products (internal and external)? With it’s processes?

   4a- How well are you at executing on these opportunities for improvement?

5- Do you feel you are getting sufficient support to fulfill your  job role?

6- What are your biggest pain points in your job (or what keeps you awake at night).

Meeting Setup:

While the questions are the secret to a successful series of interviews, you need to make sure you set things up for that success.

Invitation: Contact each stakeholder individually. Request 30 minutes of their times to ask for them questions related to X (new job role, project, initiative). In the invitation include the one slide overview (see below) and a copy of the questions you will be asking. Never send this out as a broadcast message. Each person should be contacted individually.

One Slide Overview:  This isn’t a presentation. This is a focus for talking points. The contents are:

Mission Statement/ Goal Statement- What is being attempted?

How Statement (Optional)- It may be helpful to include how something is going to be done in some instances. For example the Goal focuses on improving predictability, and the How states this will be done through the rollout of agile governance (for example).

Plan– For a new job this is usually the 90 day plan. For a project or initiative this should be the next steps planning, not a detailed list. There should be no more than 5-6 bullets.

The Questions: Have them prepared before hand and let your stakeholders see them before you meet with them. For about half your audience, they won’t ever look at them. However the other half will look at them and be much better prepared to answer them in the interview because you gave them a chance to think about them before hand.

Stakeholder interviews are too important to go in off the cuff. Take some time to plan them and you’ll get a lot more value from them.

“I just don’t understand how we can be so far off schedule?” I was staring at the reality of the latest monthly progress review and trying to decide just how many floors the General Manager would blow through when he hit the ceiling on getting this news.

A voice echoed out of the dark corner of my barely illuminated office. “Just imagine how far behind schedule you’ll be next month.”

Wonderful, just what I needed at… was it really 9:00 pm? I grabbed my coat and hurriedly shoved my computer into its bag. “Not now, Hogarth, I need to get home.”

The 800 pound gorilla emerged from the shadows, his inky black fur blending with the darkness so that only his glinting eyes and brilliant white teeth showed clearly. “No problem, I’ll walk with you.”

I signed and pushed out of my office doing my best to ignore Hogarth.

“Tell you what,” he said as he lumbered behind me. “Do me one quick thing and I promise to not pester you for a week if it doesn’t change your view.”

I stopped and turned. “Fine, deal. What do you want?”

Hogarth pointed at the cube lined hallway in front of us. “I want you to walk down the middle of this aisle, without hitting anything.” Before I could tell him just how easy and stupid that sounded he held up a massive hand. “Oh, while you are walking this way, you must keep your eyes on that wall clock over there to the right. No matter what you can’t take your eyes away.”

” Seriously?” I rolled my eyes. “Fine, just remember, you promised not to bother…” WHAM!

After picking myself back up from the floor I looked to see who the heck had left one of the rolling file cabinets in the middle of the hall. Only problem was I was looking up at the side of a cube wall. I’d not only not stayed in the middle of the hall, I’d veered into one the side halls and then into the wall of the corner cube.

Hogarth offered me a hand up. “You knew where your goal was. What happened?”

I brushed away his hand and straightened my coat. “If I was allowed to look where I was going…”

“So you mean like checking your project status more than once a month?”

I really hate it when he’s right.

We Achieve Goals We Look At

How is making your goals like riding a horse?

Some time back I introduced you all to Peet, my horse. At the time Peet was helping Hogarth and I explore a point regarding too much focus on work being bad for you. Today Peet and Sky, my wife’s horse, are back to help us demonstrate why keeping the goal in sight is so very important. If you ride a motorcycle, you already know what I’m about to demonstrate.

About twenty years ago, my girlfriend (now wife) told me I had no business ever riding a motorcycle. She said something to the effect that I didn’t have the focus. Being an overly confident young man I naturally disagreed with her. I mean I was a guy, I could do anything right? Well luck, fortune, or fate prevented me from realizing my dream to own a BMW Touring bike. This was one of those times to be thankful for unanswered wishes.

About eight years ago I started riding. My wife got me into it and I am forever thankful. As I talk about in the Gorilla Robot blog, it gave me a sense of peace and relaxation I had been lacking. It wasn’t all wine and roses though. About three months after owning Peet I took my very first solo ride. When I came back from the ride I found my wife and asked her “You remember when we first met, you told me I should never ride a motorcycle?” To this she answered something to the effect of, “yes and you still shouldn’t”. I nodded to her and said “you’re right. If I can make an intelligent animal walk into a tree, I have no business on a motorcycle.”

What Peet demonstrated to me that day was the principle of “you go where you look.” In the opening  photo is another very real demonstration. When cutting cows (herding), if you don’t keep your eye (and the horses eye) on the cow, they will happily go where ever they want. If I were to have looked away (I did), then Sky would have (he did) and the cow would have run back to the heard (she did). 

When you drive a car, the car is amazingly forgiving. If you look off to the side of the road, you don’t immediately swerve. You will, given time, but the car is very forgiving. Horses and motorcycles are not if you lose focus, if you start looking at something on the side of the road, very soon you’ll end up on the side of the road. Your entire body shifts when you look and aligns to move in the direction you are looking. With horses and bikes you see this effect very easily.

And the principle applies to goals and objectives as well. My mind really made the connections this week, when I attended the Bay Agile Leadership Network. Dan Kimble of Resonance Executive Coaching came to speak on the topic of the Leadership Crisis in the Digital Age. Dan has done competitive motorbike racing and drew the example between where you go on a bike and where you go with your goals. Being a horseman (who once nearly rode his horse into a tree) I instantly saw what he meant.

Think back to high school and the English final. You know, that multi-page essay about some book that at the time you would have rather read anything but it? You had a whole month to do the project. Yet how many of us didn’t even put the first word down until the week it was due? And how many of you wrote the entire paper the night before?

When we don’t keep our goal in sight, we don’t reach our goal.

So what can we do?

Do One Thing

Back in 2013 I expounded on not Multi-Tasking. This is not just for your day to day work, it’s for your goals as well. Try not work on two life goals in the same week, neither will get the proper attention they deserve. Since you’ve already broken these goals down into tasks (you have, right?), just focus on one task at a time and if a week is like an agile sprint, and the goal the product, work on only one product at a time.

The Daily Goal Look

Let’s pull a page from the agile community and hold our very own daily standup. Every day a Scrum team gathers around the task board and go through the three question ceremony. When they do this, they are not just reviewing what happened yesterday and what they plan to do today. They are also focusing again on their goal. The backlog shows their goal for the Sprint and every day they are focusing back on that goal. When you only review program status once a week, that’s four business days (and a weekend) to get distracted and end up completely off track.

So every day, connect with your goals again. This can both be your current work goals (what you’ll do this week) and more importantly your purpose goals. This won’t take long, just five or ten minutes a day. Your purpose goals should be no more than five at any one time and you can only do so much work in a week so don’t overwhelm yourself. Just reconnect with your goals so you can get to them at the end of the ride instead of running into the wall.

Until next time…