Skip to main content

Author: Bob Zimmerman

The Great Facilitator Part 4: What Great Facilitators Know About Estimating

Bob_Z_mar_27_28309844_XSIn my previous article, I shared an exercise that helps teams understand how to develop a plan that is manageable and achievable. I call this “Commitment-Based Estimation.” Now I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to do a great job in facilitating estimation sessions, I’m going to discuss how to select the best person to facilitate these sessions.
I typically find that the Team Lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who will allow the team to own the estimate.
When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to optimize an estimate constantly, then the team won’t feel ownership. This is not how to get a Commitment-Based Estimate.

Similarly, when an Architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

The One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.
Now you may be thinking: Does this mean I can never challenge a team? It does not. What it does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.
For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Great Facilitators Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic. I talked about this recently on my blog, in a post called “Attitude of Estimation.” As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered. Project Managers can offer perspective on dependencies and resource availability. The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects and the database team also need to weigh in. Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

In my opinion, too many people take the facilitator role for granted. I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them. A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

Get the whole picture by checking out the other 3 parts of this series –

Part 1 –  Part Business Analyst. Part Orchestra Conductor. Part Psychologist – Do you think of yourself as an effective facilitator but unsure how others perceive you? Maybe you’ve been at a meeting recently where the facilitator is doing a fantastic job but you just can’t figure out exactly she is doing differently. The differences are subtle.  This series is about those subtleties that separate the great facilitators from the mediocre ones.

Part 2 – Check in and the Chair:  Why can some facilitators effortlessly lead their team to achieve brilliant clarity and enthusiastic alignment? This article includes some basic practices great facilitators use to manage a room and deliver impressive results.

Part 3 – Commitment Based Estimation: In order for an estimate to have teeth, the team must feel ownership of the process and genuinely believe the estimates are achievable. This article includes exercises to facilitate estimates that are realistic and manageable. 

Don’t forget to leave your comments below.


Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.

The Great Facilitator: Part 3: Commitment-Based Estimation

I want to tie together two concepts I have written about during this series of articles; specifically, how proper facilitation can help a team confidently develop a plan that is realistic and manageable. This is what I call Commitment-Based Estimation. Simply put, Commitment-Based Estimation is an estimation approach that helps a team:

  • Develop estimates they genuinely believe are achievable
  • Feel ownership for their estimates
  • Manage their commitments

Why Commitment-Based Estimation Works

I’ve used the following facilitation exercise to help teams understand some of the flaws with our typical approach to estimation. This activity also demonstrates why Commitment-Based Estimation can lead to much higher-quality results.

I always do this two-part estimation exercise in person and always with a group of people. Important: when you do this with others, be sure to state the following rules:

  1. You cannot ask any questions. Do your best with the information I give you.
  2. Write down your answer. This is important (especially when doing this in groups).
  3. You cannot collaborate or look at your co-worker’s answers.

Here’s how it works:

Choose a shopping mall or large shopping center that is a typical weekend shopping destination for folks near your office. The key is that it shouldn’t be across the street from your office. It should be far enough to require a planned trip to get to. For example, where I work, there is a shopping center called Oakbrook Mall, which is about four miles from my office.

Now here is the first step. I’d like you to estimate personally how long it will take to leave your office, go to the shopping center and find a store that carries designer sunglasses. Then, purchase a pair of glasses with mirrored lenses for your spouse or other family member. Then drive back to your office and drop off the glasses. Oh … and one other thing … On your way back to the office, please pick up an ink cartridge for your inkjet printer.

Now, I challenge everyone to come up with their estimates in about 90 seconds.

The First Readout…

I then go around the room and ask everyone to read exactly what they wrote down as their estimate. It is important they use the exact words! Sixty minutes is not the same as one hour.

If you do this with a group, you will get all different answers. Typically you will get:

  • Someone who is optimistic and estimates a very short time. From the office, they might say around 30 minutes.
  • A few folks will give a pretty precise estimate. For example 53 minutes, or one hour and 12 minutes.
  • Someone who might be swagging it at one hour or “an hour and a half.”

That Was the Setup. So Now You Change the Game…

After everyone has done their readouts, I then say “great job” and explain that I want them to estimate again. However, this time they have something to lose. I pretend that I am giving away an iPad or some other prize to the three folks who provide actual estimates.
So, I want them to redo their estimates. Knowing there is a prize at stake, they now have something to lose!

And Then the Fun Begins…

I now give the group another 90 seconds to redo their estimates.

If you actually created an estimate while reading along, I’d like you to take the opportunity to make it “more accurate.” Pretend you’ll win a real iPad if you create an estimate that you’re confident you can deliver on.

I then go around the room and ask everyone to give both estimates. So again, here are some typical results during the second readout:

  • The person who was optimistic at 30 minutes now says: “My original estimate was 30 minutes and my new estimate is 42 minutes.”
  • The folks with the precise estimates of 53 minutes either stay the same, or they may go up a little to 61 minutes.
  • There’s always someone that will take their estimate and actually lower it. They may go from 80 minutes down to 70. (This baffles me.)
  • And every once in a while someone “pads” their estimate and says “one full day.”

Seriously — The Lessons We Can Learn …

While this may seem like a hokey exercise, let’s look at some very valuable takeaways:

  1. When we give our estimates, do we take them seriously enough? The goal of the entire activity is to realize that if we have something at stake, we will actually estimate differently and come up with an estimate we can confidently deliver on. So when our project teams are estimating, are they approaching this as the first go round? Are they saying, “You want an estimate? 53 minutes.” Or, do they understand there is something at stake … something much more significant than an iPad? If so, they should re-think and verify that they can deliver on their estimate.
  2. Do we assume that an estimate should be as low an estimate as possible, even if it creates risk to delivery? When we estimate, are we so afraid of estimating for real-world contingency and risk that we always estimate optimistically? We probably shouldn’t pad to a full day, but we aren’t asked to make the estimate the “best case scenario” either. It should be an estimate that we all believe is achievable and can be managed too!
  3. Can we estimate effectively without asking questions? When I do this in group, everyone wants to ask questions. Is there construction? What time of day are they going? Do they already know which store has the glasses? But as part of the rules, I say no questions are allowed. When they do this exercise, they can even be frustrated that they are being asked to create an estimate without knowing these answers. They think, “How am I supposed to estimate this”? And this is exactly what happens in real life with our project teams! It is the nature of our world that teams will always have some questions that can be answered and many others that cannot be answered. Yet, we are still asked for estimates that we can plan and execute against.

Commitment-Based Estimating is about helping a team deal with all three of these challenges and develop a plan that is both manageable and achievable.

Don’t forget to leave your comments below.


Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.

The Great Facilitator: Part 2 – Check In and the Chair

In Part 1 of this series, I talked about how facilitation is a key role most of us in the IT world play at some point. I also described the two pitfalls facilitators sometimes fall into: the Presenter vs. the Scribe. Now, I am going to share two basic practices I’ve seen facilitators use to manage a room and deliver effective facilitation sessions. These aren’t the only two recommendations, but I’ve found these practices have helped me personally manage some very strong groups.

First, the Check-in…

One challenge facilitators face is having a single person in the room dominate the discussion. There are two typical causes for this situation:

·         The first possibility is that others perceive the ‘dominator’ as having all the answers. This person has been around twice as long as us. He is also a genius. So rather than the rest of us spending 30 minutes trying to solve the problem, we can just let “Joe” tell us the answer now and finish up the meeting early.

·         The other possible reason for the ‘dominator’ is that the person who is dominating believes no one else has anything to add. They shut down others by interrupting or attacking an idea before it gets a chance to grow.

In either situation, it’s obvious that the room is in dire need of a strong facilitator. Someone who makes everyone feel that their opinion matters and the team can collaborate to achieve their desired goals.

One simple way to get ahead of this curve is a practice I call the “Check-in.” Here’s how it works: At the beginning of the meeting, as the facilitator, you describe your understanding of the overall team objective and the specific goal of the session. For example, the team objective may be planning the company’s summer picnic. The purpose of this particular meeting is to choose a theme for the picnic.

This part is simple enough. But now you need to go around the room and ask everyone to share their specific role related to today’s meeting. Now it gets trickier. Maybe one person was part of the planning committee for previous events and is there to share her experience. Another person from HR is there to help choose the theme and, more importantly, to make sure the theme is appropriate, professional and compatible for special-needs employees. There may be an individual who is there to observe, learn and support the team in activities like coordinating picnic vendors.

Because everyone shares their “role,” as a facilitator, you can clearly ask individuals to speak up. In this way, you prevent a ‘dominator’ from interrupting by explaining that “Jerry from HR” needs to express concerns from an HR perspective.

As the facilitator, you aren’t trying to control the room or shut down any individual. You are simply asking everyone to both play their role and support others in their roles.

Next, the Chair…

This technique is useful when you are facilitating a group of people and standing in front of the room. Maybe you’re at a whiteboard or easel, recording decisions or helping others capture ideas. The idea is that while you’re standing up front, there are usually four to 12 folks in the room.

When I am in this position, I always make sure to have a chair at the front of the room. If I am not physically at a table, I will have a chair just to the side of the whiteboard where I am standing. The purpose of the chair is to allow me to relinquish and regain control of the room.

For example, if there is good discussion around a topic, even if it’s disagreement, I want to encourage this discussion and let the participants feel in control of the room. I will sit down at my chair and really listen to every word.

If things get off-track or out-of-hand, or if the energy gets too low, I will get out of my chair and show my intent to start facilitating. I usually do this by raising a question.

You’re probably thinking, “Bob — are you serious?” While this seems like a very small tactic, if you are trying to lead a group, especially one that you don’t work with often, and need to make sure you are facilitating without confrontation, this is a natural way to control the energy and rhythm of the room.

Don’t forget to leave your comments below!


Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.

 

The Great Facilitator

Part Business Analyst. Part Orchestra Conductor. Part Psychologist. 

Think about what it takes to lead 100 musicians to make beautiful music together.  Or how much sensitivity it takes to understand why people behave the way they do.  While the qualities that separate a great conductor or therapist from a mediocre one may be subtle, the outcomes are obvious. The same holds true for facilitators.

Do you think of yourself as an effective facilitator but unsure how others perceive you?

Maybe you’ve been at a meeting recently where the facilitator is doing a fantastic job but you just can’t figure out exactly she is doing differently.

The differences are subtle.  This series is about those subtleties that separate the great facilitators from the mediocre ones. 

Part 1:  Scribe vs. Presenter:

Whether we like it or now, somewhere along the line we all play the role of a facilitator. How do we make sure we don’t make one of the most common and damaging facilitator blunders: Pushing our own agenda.

In the IT world, we all play the role of a facilitator.  Technical architects facilitate sessions for estimating and creating designs for their teams.  Project managers facilitate team and client meetings and make sure the team is on track to reach its goals. When Business Analysts collect requirements, they may facilitate large requirement meetings.  With so many kinds of facilitation roles, can we assume we know what being a facilitator really means? Do we, as facilitators, recognize that this is a significant role we need to work at in order to be effective?  And, most importantly, how do we make sure we stay “within” our role as a neutral facilitator and not push our own agenda?

So you think to yourself, “Yes, this is obvious. Of course I am an effective facilitator.” But let’s test ourselves to find out how effective we really are. 

The Two Extremes of Ineffective Facilitation

When I’ve been a less-than-effective facilitator, I’m usually acting in one of two extremes. I either go into “Presenter” mode or into “Scribe” mode.  Let me demonstrate these two extremes.

First, the “Presenter”.  Although their role is to facilitate a discussion (e.g. illicit requirements from business users or help a team arrive at estimates), “Presenters” actually come to the meeting with an opinion, specifically, a desired outcome. They are there to help others meet his or her agenda, rather than facilitate the room to develop its own opinions.  When a facilitator starts presenting, he or she does not allow others in the room  to collaborate towards finding their own solutions.  This shuts down the energy in the room. This also means the participants may not “own” the solution.

At the other extreme, a facilitator goes into “scribe” mode. When a facilitator is in scribe mode, it means that when he or she walks into the meeting, they sit and take notes or  meeting-minutes but do not influence the dialogue.  This approach makes it easier for  others in the meeting to go off-topic and start discussing points not related to the objective of the meeting. Also, if someone is “checked-out” or “shut down”, there is no true facilitator in the room to make sure their voice is heard.

What Makes a Great Facilitator?

While most facilitators bring their own approaches to a session, the best facilitators allow  the solution to be defined and owned by the individuals they are facilitating. She has the tact and skill to:

  • Help the team clarify and align on their objective. Then, facilitate by making progress towards the objective.
  • Help keep the group’s energy high so everyone contributes, is engaged and feels heard.
  • Keep momentum or rhythm flowing towards the objective. (Although they can help the team change direction if the team believes it is required.)   Staying on track can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective vs. topics that derail the goal. 

What About You .. Presenter? Scribe? Not sure?

Even if we believe we are doing an effective job at facilitating, we may actually be playing a Presenter or even Scribe.  Here are some ways we can test our effectiveness:

  • Are you directing conversations with your own agenda? Or, are you enabling the team to have its own conversations?
  • Are you making sure the team stays on topic and on track to meet its objectives?
  • Are you making sure everyone in the room is being heard? Is anyone’s  idea’s being  shut down? (This can affect the energy of the room.)
  • Did you leave your opinion at the door? A good facilitator helps get to a solution, not give a solution.
  • If you had not attended the meeting, would the team have accomplished the same result? (Maybe you are not being as affective as you think you are.)

When It Comes Together…

Simon Sinek recently shared the following quote:  “Don’t show up to prove; Show up to improve”.

When great facilitators lead meetings, they enable a dialogue that allows the room to make a decision. They do not abuse their role to force an outcome. Instead, they help everyone do a better job and accomplish fulfilling work. The room fills with energy and momentum that can’t avoid delivering results. When meetings feel this energy, you know you are leading the room as a great facilitator.

Be sure to watch for the rest of the series in upcoming articles:

Part 2 – Check in and the Chair:  Why can some facilitators effortlessly lead their team to achieve brilliant clarity and enthusiastic alignment? This article includes some basic practices great facilitators use to manage a room and deliver impressive results.

Part 3 – Commitment Based Estimation: In order for an estimate to have teeth, the team must feel ownership of the process and genuinely believe the estimates are achievable. This article includes exercises to facilitate estimates that are realistic and manageable. 

Part 4 – What Great Facilitators Know about Estimating: While estimation sessions can be tricky to facilitate, a great facilitator can make their teams super confident about their estimates. This article includes some ideas on overcoming the subtle challenges that can undermine the estimation process.

Don’t forget to leave your comments below.


Bob Zimmerman is the Vice President & CTO at Geneca. His career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth.

As Geneca’s CTO, Bob Zimmerman is the driving force behind Getting PredictableS.M., the requirements definition best practices that are the foundation of Geneca’s mission to make software development predictable.

What Abbot & Costello Can Teach Us About Requirements

When I was growing up, I used to love watching old black and white comedies, particularly Abbott & Costello.  If you’ve never seen their classic “Who’s on First”, you can find it right here on Youtube.   Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team.  The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base.  Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”.  A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements.  I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks?  Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen.  The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary.  Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language.  That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate.  If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code.  We all think:  How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out.  Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way!  We only need the Severity 1, defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects?  It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding.  Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are either both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers.  Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

Don’t forget to leave your comments below.


Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.