Telling the Gorilla he’s naked is a mistake

CC0 Public Domain -

CC0 Public Domain –

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.


Gorillas play with Legos: An Enterprise Scrum Simulation

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

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.


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.


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!



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 (, which is in turn based on the XP Game created by Vera Peeters and Pascal Van Cauwenberghe ( It also draws inspiration from the Lego Scrum Simulation by Alexey Krivisky (