Sprint Planning start well, end better. 

Photo Credit: Pixabay- WOKANDAPIX

“Plans are worthless, but planning is everything.”

Dwight D. Eisenhower

Has any of this happened to your Scrum Team? 

  • The team regularly takes on more work than they can complete in a Sprint.
  • Work is removed from the Sprint because it could not be completed.
  • The quality of the final work is low, with many issues found after the Sprint.
  • Stories grow in size during the Sprint as more work is discovered.
  • Arguments erupt on the right approach to getting work done.
  • Sprints looked successful, only to have the stakeholders say it doesn’t meet business needs.

These challenges and more can be traced back to poor Sprint Planning. 

The Basics of Sprint Planning

Sprint Planning marks the start of each Sprint. It sets the overall tone for Sprint. Good Sprint Planning leads to a good Sprint. A Sprint that doesn’t generate value is creating waste. 

Let’s start with a quick primer on the five Ws of Sprint Planning:

What? (Definition)A planning event to create the Sprint Backlog, which answers the questions: “Why are we doing the Sprint?”, “What work will be done?” and “How will the work be done?”. 
Why? (Purpose)To create alignment on the purpose and work needed to deliver on the Sprint Goal. 
When?Sprint Planning is the first event inside the container event of the Sprint. The Sprint starts when Sprint Planning begins. 
Who?The Product OwnerThe DevelopersThe Scrum MasterStakeholders and SMEs as needed
How long?Two hours per week of Sprint

Now we’ll unpack some of these to understand better and learn how not doing them could impact your Sprint…

Unpacking Sprint Planning

Why do we do Sprint Planning? 

We do Sprint Planning to create alignment and purpose around the Why, What, and How of Sprint Planning. 

  • Why is it valuable? (Creating the Sprint Goal.)
  • What can be done in the Sprint? (Populating the Sprint Backlog.)
  • How will the chosen work get done? (Breaking down the work)

If we don’t answer all three questions, we don’t have true transparency of the work and how it connects to the whole. 

The most common places I see Sprint Planning, and by extension the Sprint, fail is with the Why and the How parts of Sprint Planning. 

There is no Why: No Sprint Goal.

The Scrum Guide defines the Sprint Goal as “the single objective for the Sprint.” To this definition, I add it is “a concrete stepping stone towards the Product Goal.” 

If your Sprint Goal does not connect to your Product Goal, then you are not “maximizing the value of the product resulting from the work of the Scrum Team.” Without value, you can’t be profitable. Without profitability, you can’t be a sustainable business. 

Defining a Sprint Goal at the beginning of Sprint Planning is critical. Defining the goal upfront allows all the work pulled into the Sprint to support the Sprint Goal, enabling the output and outcome of the Sprint to contribute towards the Product Goal. 

There is no How: The work is not understood.

One of the reasons for Sprint Planning is to create alignment between the Product Owner and Developers. Alignment is not just between the Product Owner and the Developers. It is also between the Developers. Does the database expert know how the business logic person will implement their work? Is everyone clear on how the end product will be tested? How will we demonstrate this? If the team is not asking these questions in Sprint Planning, you are headed for rocky waters.

Who attends?

Many Agile teams treat the Events like secret Star Chamber meetings requiring a password to enter. Scrum works on the fundamental pillar of Transparency. Without transparency, everything else in Scrum will suffer and eventually fail. 

With Sprint Planning, transparency is essential as it is the last chance to refine and understand the team’s work in the Sprint. Inviting the business stakeholder to provide greater context, or the Architect, to work through some design questions can be the difference between a Sprint Review where everyone says, “That was awesome!” and one where you hear, “That’s not what I wanted” or “You realize that’s not security compliant and you need to redo it?”

How long?

The Scrum Guide says: 

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

Eight hours? That’s an entire day! Are you serious?

Let’s do a little math here. A one-month Sprint is, on average, 20 days or 160 hours. Eight hours is just five percent of the total time of the Sprint. Five percent!

Now let’s look at a typical waterfall project. Twenty years ago, the projects I managed were typically 12 months long. The first three months of that project were back and forth between product management and development on precisely what would be built with no code being written (for this release) for at least two months. Plus, the product managers had previously written requirements documents for at least two months.

Twelve months, with two months spent in “planning.” That’s 16 percent of the release spent on planning. And let’s be honest, that’s probably on the low side by a generous margin.

So, yes, two hours per week of Sprint is not only reasonable, it’s responsible. We’ve already looked at the two common failure patterns above. Lack of sufficient time is not only our third failure pattern, it also causes the first two. 

And let’s remember; the Scrum Guide says “a maximum of.” If the team finishes before the timebox, no one will complain and demand you all stay until the timebox ends. Schedule the time so you have it. Nothing is worse than having a two-hour meeting and finding out you needed two hours and fifteen minutes. 

In the next section, I’ll show you my agenda for a two-week Sprint.  

Agenda for an Effective Sprint Planning Event

The following is a recommended agenda flow for a two-week Sprint and has a four-hour schedule. 

Set the StageWelcome attendees and set expectations~5 min
WhyThe Product Owner describes a possible Sprint Goal and then discusses it with the Scrum Team~10-20 min
WhatFinal Refinement and Estimation occur on Product Backlog Items (aka stories) that the Product Owner desires for the Sprint~15-45 Min
WhatThe team reviews their availability and past performance to determine their potential capacity for the Sprint~10-15 Min
WhatPopulate the Sprint Backlog with the Product Backlog Items that will meet the Sprint Goal~15-30 Min
HowThe Developers plan how they will complete the items in the Sprint Backlog~2 hrs
CloseTake a final confidence vote, thank the team, and end~5 min

1. Set the Stage: In their book Agile Retrospectives, Esther Derby and Diana Larsen say, “Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective.” The above is good advice for all the Scrum Events, and I start Sprint Planning by thanking everyone for their time and reminding them of the purpose of Sprint Planning.   

2. Establish a Sprint Goal: We’ve already discussed how failure to create a Sprint Goal or even creating a Sprint Goal after deciding what to do is one of the top reasons Sprints fail. If Sprint Planning sets the tone for the Sprint, the Sprint Goal sets the tone for the planning. 

The Product Owner should come prepared with a recommended Sprint Goal. This Sprint Goal can result from the Sprint Review the day before or based on other strategic work. To be effective, the Sprint Goal connects directly to the Product Goal. The team then discusses, refines, or changes the Sprint Goal. 

3. Final Refinement and Estimation: You should already be doing regular Backlog Refinement to keep your Product Backlog topped off with regular work. That said, Sprint Planning is the “last responsible moment” to do refinement. Check out the Scrum Alliance article linked above for more on Refinement. 

Generally, I see three kinds of refinement happening during Sprint Planning. From most common to least, they are: 

  • Reestimation of work
  • Updated Acceptance Criteria
  • New, usually urgent, work

Reestimation can happen at any point up to when the team starts working on the item. Say that the last refinement session was the Thursday before. Since then, Sunil has been rummaging around the data layer and has discovered several new connections to other processes. Sunil returns to the team and says, “I think we underestimated the complexity.” The estimate for the item could change right there in Sprint Planning. 

Acceptance criteria are how the Product Owner can shape the value of the work. The PO may want the new login page to be 25% faster than the last one. Martha has been looking left, right, and sideways at the code, and she doesn’t think the team can squeeze more than 15% out of the current system. The PO then decides if getting the new login page now is more important than getting it to load faster. The PO wisely decides now is better and agrees to change the AC to a 10% improvement. 

And finally, remember that the Product Backlog is dynamic and emergent. New items can shoot to the top of the backlog overnight. The Product Owner may bring a brand new item to the team and ask them, “Can we refine this and include it in this Sprint?” While this should be uncommon, it should also be possible.

4. Determine Sprint Capacity: How much work can the team do on average? Will anything impact the team’s ability to work this Sprint? A great example is what to do when a major holiday falls in the Sprint. Instead of the team shortening the Sprint, they consider how this will impact them. If the entire office shuts down for a week, then the team’s capacity is 50% of what their velocity says they can do.

5. Populate the Sprint Backlog: Once you have a capacity guide for the Sprint, the team can fill the Sprint Backlog with work that supports the Sprint Goal. There are many ways to do this. Just remember that the Developers pull work into the Sprint. The Product Owner decides if the work to do has value and contributes to the Sprint Goal; the Developers decide how much work they can do in a given Sprint. 

6. The Developers plan how they will complete the items in the Sprint Backlog: This is the most frequently forgotten — and therefore problematic — part of Sprint Planning.

 Here’s how I explain this to  students:

 “When Sprint Planning starts, you are coding! Not all coding is hands-on keyboard typing. There is whiteboarding, design conversations, coordination, and more.”

If the developers need to look at the code to determine how they will build something, then look at the code. Scrum Masters, this is one of the places you are most needed. Ask questions, and seek clarity. Does the team understand what they will do, or are they planning to “just figure it out as we go?” That’s not Agile; that’s just lazy. 

The How phase is the most time-consuming part of Sprint Planning. Done well, it prevents rework and conflicts (people, process, and product). It allows for a greater chance the team will deliver a usable increment of value (AKA done work the customer cares about) at the end of the Sprint. 

Here are some things Developers should be doing in Sprint Planning:

  • Break work down “into smaller, more precise items.”
    • AKA create individual tasks that represent the technical work needed to complete the Product Backlog Item. (UI work, DB work, code review, create automation tests, etc.)
  • Whiteboarding the design
  • Sketch the user interface
  • Review existing code
  • Anything required to plan how to complete the work

Breaking work into tasks is vitally important and should never be pushed out with a “we’ll figure it out later.” Tasking allows for: 

  • Remembering the work: Five days from now, will you remember what you discussed in the Sprint Planning meeting? And if you didn’t even talk about it at Sprint Planning, do you remember when you did talk about it? 
  • Alignment: How will the UI work fit into the Business Logic work?
  • Track Progress: If you break work into tasks of no more than four hours, your burn-down charts will reflect progress toward the Sprint Goal more accurately. 
  • Create stronger teams: When the team breaks work into bite-size pieces, it often allows someone with less skill to pick it up and complete it. This benefits the team in creating more cross-functional members and benefits the individual who gets to improve their mastery. 

The Product Owner during the How

What does the Product Owner do during the How part of Sprint Planning? Unfortunately, the typical pattern is “See you all later; let me know how it goes.” 

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” 

The Scrum Guide.

The work is still all about value. If the Product Owner isn’t present, important questions might go unanswered, acceptance criteria can’t be tweaked, and problems not detected until too late.  

The PO should be present and available. Their presence will ensure a continued alignment to value. 

7. Close: Closing can be an under-appreciated part of good Sprint Planning. In Agile Retrospectives, the authors say, “End the retrospective decisively: don’t let people (and their energy) dribble away.” 

Remember the maximum timebox. If the team is still going strong at three hours and fifty minutes, the Scrum Master can ask the team what’s needed to wrap up. Maybe they didn’t get all the work planned out. What will they do about that? Do they need to de-commit some work before the Sprint starts? 

One of the things to do here is to collect a confidence vote. Now that the Developers have planned the work, how confident are they that they can complete it all in the Sprint?

Using the Fist to Five consensus framework is an excellent way to check on confidence.

Working with multiple teams

What happens when a Product Owner is supporting multiple teams? This is not immediately a bad thing. The Scrum Guide even has a suggestion:

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” 

The critical point here is that to be effective, the Product Owner must only have one Product Goal at a time. The next question will be, “How many teams can one Product Owner support?”. 

My answer is 2

There are other answers and arguments, and we’re stepping into scaling conversations now. My experience is that a Product Owner becomes exponentially less effective beyond two teams. Once you move to four teams, you need to insert a scaling practice to have someone focused on the longer term while Product Owners continue to be sleeves rolled up and engaged with no more than two teams. 

In practice, the way I’ve coached Product Owners supporting two teams is as follows: 

  • Shared Backlog Refinement
    • Not everyone has to be in refinement sessions. Ensure you have representation from both teams and that all skills needed to complete are represented.  
  • Shared Why and What Sprint Planning
    • This allows alignment, horse trading of work, managing dependency, and more. 
  • Individual How
    • Do these at the same time with the PO floating between both teams. 
  • Individual Daily Scrums
    • Stagger them so the PO can go to both
    • A representative from each team should go to the other Daily Scrum
  • Individual Retrospectives
    • The PO rotates attendance every Sprint
    • Every quarter or so, do a combined retro on overall ways of working. 

A good Sprint Planning Event creates Value and Quality

The concept of “Starting on the right foot” is not just a trite saying. If you want to improve the quality of your work, improve the quality of your Sprint Planning.

Does the Agile Gorilla have to be technical?


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


Telling the Gorilla he’s naked is a mistake

CC0 Public Domain - PixHere.com

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.


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 (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).


The Gorilla argues that Healthy is more important than “Agile”

banana-1949166_960_720_Pixbay_CCMy 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.



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.

Agile isn’t about going faster, so say yes.

Source: WikiCommons

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.

The not so secret ingredients of the Gorilla Coach Cookbook

Source: Wikimedia Commons

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.


Metrics: Third Rail of Agile Adoption

“Am I good or what?” The question was, of course, rhetorical, I was alone in my office. I

Photo Courtesy of: https://www.flickr.com/photos/bike/

Photo Courtesy of: https://www.flickr.com/photos/bike/

couldn’t help it though, I was pleased as punch and nothing was going to ruin my great mood.

“Or what?…”

Not even an 800-pound invisible gorilla.

“Go away, Hogarth, you can’t ruin my mood today. I’m on top of the world.”

Ignoring me, Hogarth ambled into my office. Spotting my new fichus, he plopped himself down and tore a branch from the tree. Around a mouthful of leaves, he asked: “So, agile adoption going well?”

His question instantly dispelled my annoyance at his assault on my plant. “Yes, yes it is.” I turned the monitor around so he could see. “Just look at these velocity trends! Every team is hitting or exceeding their velocity targets and we’re only three sprints in. It’s absolutely fantastic!”

Hogarth leaned in and intently studied the flat screen display. “Impressive. That’s got to be one of the fastest velocity growths I’ve ever seen. What did you do differently this time?”

“Hey, I’m just good. Awesome training, great coaching. Oh, and I bet the incentive program really helped out.”

Hogarth cocked his head to the side, “Incentive program?”

I leaned back smugly, “Oh, yeah. If the teams hit the velocity goals then they get a cash bonus and we’re going to hold a huge party at Humdingers Resort.”

Hogarth nodded, making some appreciative sounding grunts. I’d finally gotten to him. He was speechless.

After a long gaze at the monitor, he turned to me and gave one of his brilliant white smiles. “Sounds like a real Goodhart moment.”

It was my turn to cock my head in confusion. “A Goodhart moment?”

My gorilla nodded at me, “Uh huh. A well known British economist has an economic concept named after him. The layman’s version of Goodhart’s Law states, ‘When a measure becomes a target, it ceases to be a good measure.'”

I looked at Hogarth. I looked at the velocity reports. I looked at Hogarth. “You mean…”

He nodded, “Yup, those velocity metrics are about as useful as wheels on a speed boat. They look good spinning, but they are not really doing anything.”


Metrics- Can’t live with them, can’t live without them.

“Metrics are not bad, managers using metrics improperly is bad.” was a quote I sent out on Twitter (@JBC_GC) during Agile Open Northwest 2017. The session was “Why do metrics get a bad rap?” and it was a lively conversation with some surprising outcomes.

I’ve had a lot of success with the healthy use of team metrics. I’ve used the afore mentioned Goodhart’s Law as a conversation starter on the good use of metrics many times. And despite my success with team metrics I had never really articulated, to myself or others, what the disconnect between team metrics and management’s desire to set goals on those team metrics was. Turns out it is rather a simple thing.

Managers don’t actually care about metrics. They care about success.

Managers want to know if the product will ship on time or with the promised features or with the promised value, or all of the above. They end up using team metrics because it’s all they have. And in the classic square peg in a round hole scenario, they were hitting the square peg with the hammer to make it fit.

And how’s that worked out for us? Even in the well run agile project, the ability to tie team estimates and metrics to actual shipping dates is a highly mixed bag. We are horrible at estimating, to the point that the #NoEstimate movement is gaining traction through being right. This, however, is not a rant about how bad we are at estimating, using no estimates or even bad metrics. It is instead a look at what we can do about this disconnect between Team Metrics and Management need.

Step 1: Recognize managers need better forecasts, not better metrics.

Step 2: Stop using Team Metrics for forecasting.

Step 3: Give managers the tools to let them forecast.


Step 1: Recognize managers need better forecasts, not better metrics.

The best use of metrics is “as a lagging indicator of if we might want to talk to the team and see if they need help.” This is the coaching advice I give to management and teams, usually shortly after quoting Goodhart’s law. Metrics will not tell you when a team will get done without the risk that the metric will run afoul of the wisdom of Mr. Goodhart.

Just as you want to know if you should pack an umbrella tomorrow (or wear sunglasses, or get your snow blower ready), management wants to know if the project will be successful. A totally and perfectly valid request. Only you don’t use team metrics for this. Even when metrics are used as the source data, they are still being used to forecast. We look at velocity trends to estimate when a team will be done. That’s forecasting, not metrics.

Step 2: Stop using Team Metrics for forecasting:

Performance based on incentives doesn’t work. When we try and use metrics to drive performance we get Goodhart’s Law. The example I like to give comes from the book Freakanomics.

To summarize: India was having a problem with cobras. To address the problem the government came up with a great idea. They would give a bounty on every cobra head turned into the government. The program was a rousing success, just not in the way the government intended. People started raising cobras just so they could collect the bounty. In short order, India’s cobra problem was even larger than before the bounty was put in place.

If you tell a team they must make a March 15th release date. They will very likely hit that date or come really darn close. And then the company ends up dealing with bugs for the next five years. “When a measure becomes a target, the measure is no longer valid.” If you’re struggling to get your message heard, you might try showing them Dan Pink’s RSA Animate video to reinforce that knowledge skill teams don’t work best from incentives, they work best from Autonomy, Mastery, and Purpose.

Of course, not everyone is going to listen, even when they pay us for our advice.  Which is why I advocate limiting the metrics used and make them interlocking. Game one metric and the others will react in the negative. My four metrics are based on Jeff Sutherland’s three recommended metrics and a fourth I’ve had a lot of success with. They are:

  1. Cycle Time
  2. Escaped Defects
  3. Happiness Metrics
  4. Planned to Done Ratio

If you game cycle time so it’s really short, quality will almost certainly suffer. Let quality slip and you see an increase in cycle time and escaped defects. If planned to done is too high, then quality is probably suffering. And if metric 1, 2 and 4 are all really great and happiness is suffering then you have a strong indicator that you’re burning out your team.

Step 3: Give managers the tools to let them forecast.

This one is really easy. Stop reading my blog and go to FocusedObjectives.com. Troy Magennis has crossed the streams of mathematics, classic project management forecasting and agile to come up with a tool that allows managers to forecast when a team(s) or feature(s) will either be done or if it will hit the desired schedule.


I’ve seen this tool in action and heard stories from several users of Troy’s Forecasting approach. With this tool, the managers no longer need detailed metrics from the team. They can build forecasts based on as little as a half dozen data points, which can even be made up for initial forecasts. With just cycle time data points, you can run massive Monte Carlo simulations to get 80-90% accuracy on your forecasts (note, anyone who claims 100% accuracy is also gaming the system, or in denial).


So keep team metrics focused on improving the team. Give management their own tool for forecasting schedules and/or capacity. Then watch as the results of this is the teams getting, even more, work done, with greater predictability, and greater happiness.

Just say “No” to Gorilla Debt in your Teams

By ccPixs.com

Debt Free by ccPixs.xom

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

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

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

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

“Go away Hogarth, I’m busy.”

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

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

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

I nodded.

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

I nodded again.

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

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

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

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

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

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

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

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

And he’d done it again…


Team Debt is just as destructive as Technical Debt

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

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

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

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

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

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

The Impediment Backlog

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

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

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

How Agile Coaches are Like Vampires?


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

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


“Shhhh…. this is the best part”

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

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

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

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

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

“Agile coaches are really a lot like vampires.”

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

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

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


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


How are Agile Coaches like Vampires?

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

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

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

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

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

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

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

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

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

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

Have you invited your agile coach in lately?