Subscribe via RSS Feed

Category: For Practitioners

Eliminating the “Black Box Effect”

Eliminating-the-black-box1Regardless of whether you are doing iterative development or use waterfall methods, you may be struggling to get agreement on whether a delivery team is on track or falling off expectations. This blog covers techniques that can help business and technology teams agree on how to track progress of a technology project.

The Black Box: is any comparatively small, usually black, box containing a secret, mysterious, or complex mechanical or electronic device.

One of the key complaints of a pure waterfall development approach is the reality that a project may not show any results (or provide any feedback) until the software is completely finished.  In other words, the business really has no idea if the project will meet their needs or is on schedule until the software is delivered.

For example, we start a project in January.  It may take through February for initial business architecture and design to be completed.  It may take another month or two before software is actually being developed and delivered to the testing team.

The business may not get any visibility into working software for six months or more.

This is what I call the Black Box Effect. We need to find a way to eliminate this effect and have an agreed upon approach to determine whether a project is on track or not.

The benefits of an iterative approach

There are many reasons an organization may choose to move to an iterative development model such as Agile or Scrum.  One of the more important reasons is to gain more frequent feedback on whether what we are building meets the real business need.

Are you  tired of the business saying, “What did you do to me? I thought we were going to have this done.” And are you tired of hearing yourself say, “Well, I thought we were going to have THIS done!” If that’s the case, then you are obviously not in agreement and have a “visibility” problem.

Visibility isn’t a project plan!

Visibility isn’t a project plan that tracks progress. Visibility is agreeing that the business can get access to completed functionality. Visibility means the business can see how the software being developed will help them achieve their business objectives defined earlier in the process. If they can get visibility into that on a regular basis, then we can agree on whether we will be able to “high-five when the project is done.”

Not only do we need to provide the business visibility on progress, but we need to allow the business to re-evaluate their priorities based on the progress seen. Consider this a feedback loop, allowing development teams to constantly re-evaluate and tune their approach.

I use three key opportunities to provide visibility and get feedback from the business: QuickPeek, Showcase and Release.

QuickPeek

At the end of each iteration, the team should be able to show software that has been developed and completed through unit-testing. The software may not have been put through functional testing or even integration testing, but it has been completely unit tested. There may still be remaining defects.

We encourage the business to review each iteration’s results and make sure we are on track with their expectations – even if the code is not yet packaged for deployment or completely system tested. Remember, the QuickPeek  is typically informal and just to show the iteration progress.

Even in a Waterfall process, you should be able to start identifying key components being developed every two weeks that can be “viewed” by a business stakeholder for feedback.  Maybe some deliverables will take a week while others take up to three weeks.

I believe you can introduce a QuickPeek on a regular basis without too much intrusion into your current corporate process.

Showcase

When a release is going to take six or more months, there is value in planning a Showcase.  This  is a formal review of a set of features or system components.  Functional testing is typically complete and it shows complete business scenarios or processes at work.

However, it typically is not ready to be deployed like a release.

The purpose of the Showcase is to demonstrate the functionality of a complete component to a wider group of stakeholders. It is also used to celebrate progress and create a common vision around the new solution.

Even in an Agile world, you may not be deploying a release until Iteration 10 or 12.  Therefore, there probably is value in creating a Showcase around Iteration 4 and Iteration 8 to provide greater visibility and market the progress you have made.

Eliminating the Black Box creates Visibility

I hope these techniques can help even a waterfall shop create greater visibility and market the progress the team is making. Throughout the development process, it allows the business and I.T. to develop a common view of progress and decide whether adjustments need to be made to the final product.

Do you incorporate all of these techniques? If not, what are the obstacles?

Alignment: Antidote to Rework

Alignment-Antidote-to-Rework1In my last post, I introduced the Getting Predictable℠ Best Practices and explained  how they are designed to set project teams up for success “from the start”.  These practices cover three areas: Alignment, Commitment and Visibility.

Now I am going to dive deeper into the  concept of alignment and why it is critical to reducing rework and helping any team (not just IT) meet its  expectations, each and every time.

What is Alignment?

With technology initiatives, the goal of best practices around alignment looks like this: The business stakeholders all have a common answer to the question, “What is success for this project”?  In other words, they have agreement when the team can stop and everyone can  high-five because they all got what they needed.

At the other extreme (and this is the problem we are trying to solve), we don’t want the business to say to the team: “We have a really critical schedule, so you guys start and we’ll figure it out later”.

Why is it so important to focus on aligning the business stakeholders?  Isn’t it more important to focus on aligning the technology team to the business? No it is not more important – and this answer is of huge importance!

The technology team can’t align to the business goals if the business doesn’t agree on those goals! In other words, if the business isn’t in alignment, how can a technology team align?

What are they aligning to?

More importantly, a lack of alignment on the business side means there is almost certainly rework ahead for the technology team.  As the business goes through the process of coming into alignment, the IT team needs to make constant adjustments.  Sometimes in small ways, but other times the change can be significant and involve removing or changing an entire component of the solution.

When was the last time rework got extra schedule or budget?

This blog will cover those Getting Predictable℠ Best Practices that focus on helping the business get alignment on answering this question:  “What is the definition of success for this project?”.

Alignment is a great idea, but I don’t think it can work for me

Now you  might be thinking: “I can’t get my business folks to a single meeting, let alone get them to agree!” In future posts, I will share best practices that have worked for me. They don’t all work, and they don’t apply to all situations, but I have come to rely on these simple practices to get the results I am looking for.

And there is a huge side benefit.  By helping the business come into alignment on the key objectives of a project, I end up building a new level of trust in my relationship with the business team.  This truly was a pleasant surprise.

You will find some past posts, as well as future posts that focus on key areas such as:

  • Facilitation techniques
  • Aligning the business when they are geographically distributed
  • How to align interested parties that aren’t decision makers
  • Being adaptive to change and protecting alignment
  • When a lack of alignment is ok

So what do you think?

Do you believe this is a problem in your world?  How bad is it? I’d love to hear examples in the comments below.  If you don’t have this problem, why?  What do you believe you are doing right?

Getting Predictable℠ is a collection of best practices 
that set teams up for success from the start.

What Drives The Getting Predictable℠ Best Practices?

startIt’s all in the phrase: From the Start. I am frequently asked how the Getting Predictable Best Practices got started.

Getting Predictable℠  best practices cross many subject areas including requirements collection, tracking project progress, facilitation techniques, providing estimates that drive confidence, and so on. With such a wide array of practice areas, you’re probably wondering what binds them together. In other words, is there a common theme or vision that drives current and future best practices and recommendations? The answer is YES – there is indeed a common theme. And, as you guessed, this blog post reveals the vision aligns Getting Predictable℠ in all of its many flavors from discovery to definition through execution.

From the Start

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Wow! How profound! (Yes, I am being sarcastic at the moment but there’s truth here as well) For the majority of my career I have been on the client side of consulting relationships. I have heard some pretty big promises and I tend to be very skeptical. As I read my own description of Why Getting Predictable℠ exists, it’s hard not to think how empty it sounds! So let me explain. Let’s pretend we have a project kicking off and we have approximately four weeks to collect the overall requirements so the technical team can begin their planning and staffing of the project. So we e set up meeting with key stakeholders and business users for the first week in March to kick off the requirements gathering. The business is extremely busy and coordinating their schedules is like herding cats. All too frequently, you do not get full traction and commitment from the team during the first few days. In fact, it is possible that you might not get to full throttle until the second week of the four week schedule. Since we didn’t pad our four week plan, this lost time needs to be addressed. It is important for us to be adaptive and stay on schedule despite losing three to five days at the beginning. I want to emphasize that is not a rare situation. Especially when launching a new initiative. Would you agree?

Let’s take a different perspective…

Let me share a different way to view this. It may be a day here or a day there, but if we actually lose four to five days getting up to speed across the four weeks, we have lost 25% of schedule. We are potentially 25% late and over budget for this phase. And we haven’t even started yet! Here is my point: Although most of our leaders and managers would never intentionally handicap or put the team at risk, they are unaware that missing a meeting or pushing a date is actually doing harm to the team. If this story, in one flavor or another, resonates with you, then your success and the success of your project are being put at risk from the very start of your project. Why does this happen?

It’s all about the frog

If you put a frog in boiling water, it will immediately jump out. It’s way too hot. But if you put a frog in room-temperature water, and very slowly turn up the heat to a simmer, the frog will stay in its comfortable hot tub until it perishes. Ouch! On your project, it may only be a day here or a few folks there, not available, but before you know it, your project is starting to simmer. So let me repeat:

Getting Predictable℠ is a collection of best practices that set teams up for success from the start.

Getting Predictable best practices identify and address the situations, activities and events, that can slowly handicap the teams chances of success before they even get going.

Now You’ve Got My Attention. Tell Me More.

Getting Predictable℠ Best Practices cover the gambit: Discovery, definition, execution, and organizational effectiveness models. In this blog, I focus on the best practices that address defining and launching a project or initiative. I call this set of best practices Getting Predictable℠ Definition. Getting Predictable℠ Definition addresses the three key areas that impact a project right from the start:

  • Alignment: Driving alignment around project success across all stakeholders.
  • Commitment: Developing estimates and plans the team can commit and manage to.
  • Visibility: Having a common view of progress as well as a a common definition of when the team has delivered on the defined project objectives.

In my next posts, I will discuss each of these areas in detail so you can see there is a method to the madness of Setting Teams Up For Success FROM THE START.

Facilitating A Panel Is Not So Different Than Facilitating A Requirements Session

My First AHA Moment of 2012

panel-discussion-150x150Facilitation appears to be a hot topic these days. After blogging about facilitation a few months ago, I am getting many questions about best practices and how to handle certain situations. At the bottom of this post I’ll provide links to my past articles on facilitation that should address many of these questions.

Today I want to share an AHA!

Recently I was invited to speak at an event on the topic of facilitation. One of the other presentations at that conference was a typical panel presentation.

Panels are very common at conferences; they usually have three to four people and a designated moderator who helps facilitate the discussion among the panelists and engages the audience. The session typically runs about 60 minutes.

These panels tend to be very dry (yawn)

For most panels, questions are devised ahead of time and shared with the group so they can prepare their agenda, personal messaging, and so on. I should clarify, that some panels are engaging and are very interesting. But at times, I come across a panel where each person seems to be coming from his or her personal point of view. Their views may not be clearly aligned to the question. So you get someone speaking strategically, while another may be extremely tactical or even not directly speaking to the question.

Let me magnify my point. Each member of the panel will work with the moderator to identify the question(s) they would like to be asked so they can share their viewpoint on a topic. And since three or four different panelists do this as individuals, possibly at separate times, it can be dry, without a clear set of takeaways.

I want to be clear, that there are many panel presentations that are engaging and valuable. But more often than not, I personally find them dry. As an audience member, you are trying to get a grasp of the discussion topics and understand the panelists’ points of view. However the very disparate nature of the moderator’s Q&A prevents engagement between the audience and the panelists.

Changing the dynamic of a panel…

This makes me want to try something new the next time I am invited to be a panel moderator.

I would want the audience to engage more with the panelists on stage. To get more energy, the format of the panel would have to be a little different. We are used to a panelist getting asked a question, then answering their question, followed by each of the other panelists attempting to provide answers to these preset questions which they may or may not have a valuable answer for. Then it starts all over when the next question is thrown out.

With my new approach, after the question is asked, instead of always asking all the other panelists to answer the same question, I will ask the audience members to give their perspective on the panelists’ thoughts. This would raise the engagement level of the audience with the panel.

My job as a panel facilitator would be to facilitate the rhythm of the discussion between the audience and panelists. This means I must meet with the panelists before the conference to create an agenda that would allow us (facilitator and panelists) to agree on a common objective. This would enable the panel discussion’s rhythm to flow more smoothly, be less fragmented, and not break the energy of the room.

I have already outlined in past posts, that the key to the most effective facilitators is that they monitor three things: energy, rhythm and objective of the room. The same can hold true for panel moderators (aha!)

  • Energy in the room: Everyone is engaged, participating and making constant progress toward accomplishing objectives. (For panels: Keep the audience engaged)
  • Rhythm of dialogue: The dialogue flows, but stays focused on the initial goal of the meeting. (For panels: Make sure energy does not get broken by unrelated, fragmented questions)
  • Objective of the room: Make sure the meeting stays on track and accomplishes its objective. This can be tricky since the facilitator needs to balance discussion on side topics that are helpful to the objective versus topics that derail the goal.(For panels: Make sure the questions address a common theme)

I think there would be huge value in using these fundamentals when moderating a panel discussion.

When did you last attend a panel that really impressed you and what was so unique about it?

What are your thoughts about changing the dynamic of a panel presentation?

You can find more details on facilitation best practices in my past blog posts here:

They are some of the fundamentals that I present in my regular class on Facilitation Best Practices.

Measure Twice, Cut Once

The Role of the QA in Making Software Development Predictable

measure-twice-cut-once1A Guest Post for the Getting Predictable Blog

Measure Twice, Cut Once is about having a plan, being prepared, and having a systematic approach before taking action. Whether it’s installing new cabinets in your kitchen or writing a new software application for a client, no matter what type of project you’re working on, you can minimize your chance of making costly mistakes by double checking your measurements/requirements before cutting materials or writing code.

I learned this very valuable piece of information growing up with a mother who loves to sew. As a kid I would always ask my mom if I could help. Since sewing requires measurements to be as accurate as possible, a standard practice was enforced when working with my mother to double check my measurements before I cut anything! I always thought the reason she made me double check everything was because I was a kid, until one day I noticed my mom double checking her measurement as well. So I asked her, “Why do you measure the fabric twice before cutting it?” My mother replied (as she continued measure every part of the fabric), “Because this fabric costs too much and my time is too valuable to be wasted.”

She continued to say, ”Let’s say I cut too much fabric. I have now wasted fabric because I have to cut off the extra fabric which takes time. Or, let’s say I cut the fabric too short. Now all that fabric is wasted and I must cut a new fabric layout which also takes time…”

“This dress should take me one day to make but if I’m constantly re-cutting fabric due to measurements being off, then it can take me twice as long. My original estimate of how many outfits I could get out of it will also be off. Plus, I will have to go back to the store to get more fabric. But if I just double check my measurements I save myself time, money and a headache.”

QA. (not to be confused with Tester)

This is true for IT projects as well. If the requirements (which are the measurements for a software project) are being doubled checked, the project will have a minimal chance of wasting resources, time and money.

One approach to ensure that this double check is being done is to get the QA involved at the requirements stage. While having a tester involved at this stage is not the most efficient use of resources, having a Quality Assurance Analyst (QA) definitely is.

Many IT professionals are not aware that there is a difference between a QA and a Tester. A QA is an IT professional who makes the blueprints for processes and procedures. These blueprints will ensure quality is maintained throughout the lifecycle of the project. A QA also understands how to design test cases in a way that they are competent, effective and easy to execute. A tester is someone who executes test cases that, in some cases, have been written by a QA. If a QA is involved with the requirements stage, the requirements will be unambiguous and succinct.

The QA will also check the requirements to ensure that the following has been covered:

  • Look and Feel: – How does the interface make the user feel and behave?
  • How and why the system works: What will happen when this button is clicked and why?
  • Contradictions among scenarios: Does one scenario say the opposite of another scenario?
  • Root causes for gaps in the system/process: Are scenarios defined well enough? Is the workflow depicting a different picture than the information given?

The more robust the requirements, the better the final product.

During the requirements phase, the foundation that the entire project depends on will be formed. Given that over 50% of project defects are introduced during the requirements gathering phase, it makes sense to have a QA involved to double check that gray area requirements do not get overlooked and to help define error messages and usability issues. Just like a sewing project, fundamental issues left unchecked will surface later in the project.

“Measure Twice, Cut Once” is a reminder that careful project planning will result in more predictable results.

The Role Call: A New Practice to Set Your Team Up for Success

The-Role-Call-ChecklistLast post I wrote about how often we begin a project from a disadvantage right from the start. Usually it’s because the team doesn’t have the resources or the commitments it needs from outside of the team.

In this post, I want to talk about a new best practice I am experimenting with. This practice is  designed to help set teams up for success by focusing on the project team resources. I call this best practice: The Role Call Checklist.

Key Roles On a Project

First I need to  explain the common thinking on key project roles: Specifically, every project is made up of 4 key roles. In no particular order, these roles are:

  • The Architect: This is the person responsible for the technical solution. For example, “does it work or do you get 404 or blue screens of pain”?

 

If the final application doesn’t technically work, or if it doesn’t meet a non-functional requirement, such as scale, then the Architect is accountable. I am not going to follow up with the Project Manager. It’s the Architect’s responsibility.

  • The Senior Business Analyst: This role is about  understanding what business problem this project addresses and, from a business point of view, what is success. Business Analysts are the proxy for our business users.

 

If the final solution works technically, but doesn’t do what the business needs, and doesn’t allow the business to achieve their goals, then the Senior Business Analyst is responsible.

  • The Senior Quality Analyst: QAs are responsible for the quality of the solution. Before everyone jumps on me, I don’t want to get into the discussion of exactly what the QA role is and how encompassing it is. I am a true believer that the QA role is larger than a testing organization. Their job is not to simply test and place a sticker on the software saying “Inspected by #12”.

But for this post, I hold the Senior Quality Analyst accountable to identify what quality the system holds.  What are the defects and is the system compliant with the intent? If the system technically works, and if it was designed to meet the business needs, then the Senior Quality Analyst is accountable to say whether it is ready to ship.

Finally,

  • The Project Manager: The PM is responsible for overall transparency.  This person needs to have an accurate picture of where we are in relation to schedule, budget and meeting Business Objectives. Further, they are accountable to serve the team by helping to identify and, more importantly, facilitate removing obstacles that can prevent the team from being successful. They are the manager.

Although I believe every project, small or large, has the need for these four roles, they don’t necessarily need to be four separate individuals. On smaller projects, you may have a single individual playing the Project Manager and Business Analyst role.  Or you may have the Business Analyst playing a Quality Analyst role. It depends on your culture and the strengths of your team members.

But the need to define:

–        What you are building,

–        How you are building it,

–        Whether you built it properly, and

–        How you’re managing the process

is required on every project. When a smaller team doesn’t believe they need each of these roles, it can create a gap to successfully delivering a solution.

And this brings me to the new best practice I am experimenting with:

The Role Call Checklist

I create a mini-checklist for each these roles. Under each role, I write what the role is accountable for. While there probably will be a common list of  responsibilities across many of our checklists, each role will also have some unique views.

If you are assigned a new project, I recommend creating this checklist to determine who is playing each of these roles.  On a smaller project, you may have one person playing two or three roles.  On a larger project, you’ll want to  identify the key owner of each role.

Then, I recommend that you meet with your team and make sure you are all in agreement as to who is doing what, and what the team is relying on each person for. I believe this small exercise can help a team start more successfully, especially when resources are scarce.

If you have a checklist, I would love to hear from you and find out what works and what doesn’t.  Does it make a difference?  Are you willing to share yours?  Feel free to add a comment below.

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

IT-Great-Facilitator-4Last post, I shared an exercise that helped 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 be effective at 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 can 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 constantly optimize an estimate, 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

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 is 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 Good Facilitators Can 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 in a past blog 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.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who 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.

IT as Great Facilitators Part 3

Commitment Based Estimation

IT-as-Great-Facilitators-Part-3I want to tie together two concepts I have blogged about in the past few months. 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.  As a quick review, Commitment Based Estimation is an estimation approach that helps a team:

  • Develop estimates they genuinely believe are achievable
  • Feel ownership for their estimates
  • Treat these estimates as commitments and therefore honor them by managing to their plan

You can find my previous posts on this topic here:

Experiencing 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 2-part estimation exercise in person and always with a group of people. Important: If 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.

I’d like you to 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, but requires 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 personally estimate 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 the estimate above. They each get about 90 seconds to come up with their answers.

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 they wrote down. 60 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 says a very short time. From my office, they might say 30 minutes.
  • A  few folks who 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 could win a real iPad if you create an estimate that 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 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.
  • (This baffles me.) There’s always someone that will take their estimate and actually lower it. They may go from 80 minutes down to 70.
  • And every once in a while someone “pads” their estimate and says “one full day”.

Seriously – the Lessons We Can Learn …

This seems like a hokey exercise. Yes – I am a hokey person 🙂 .  But let’s look at the real takeaways:

  1. When we did our first estimate, we didn’t take it seriously. The goal of the entire activity is to realize that if we have something at stake, we will actually estimate differently, and try to 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 around?  Are they saying “You want an estimate? 53 minutes.”  Or do they understand there is something at stake?  They should re-think and verify that they can deliver on their estimate. Do they understand there is much more than an iPad at stake?
  2. 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 to!
  3. When I do this in group, everyone wants to ask questions.  Is there construction?  What time of day are they going? Do they know what 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 still ask them for estimates that we can plan and execute against.

Commitment Based Estimating

Commitment Based Estimating is about helping a team deal with all three of these challenges. In my next post, I will talk about how proper facilitation can help a team deal with these challenges and deliver a Commitment Based Estimate that everyone believes in and the team can manage to.

Can you think of any situations where it would have been worthwhile to try this exercise before delivering an estimate?

IT as Great Facilitators Part 2

IT-as-Great-Facilitators-Part-IIIn my last post I talked about how facilitation is a key role, we each provide,  in the IT world. 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 have found they help 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 and is a genius. So rather than the rest of us spend 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’s given a chance to grow.

Both of these situations means that the room is in dire need of a strong facilitator. Someone who  can help everyone feel that their opinion matters and collaborate to achieve their desired goals.

One simple way to get ahead of this curve is a practice I call the “Check-in”.  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 next company outing which is a picnic.  The purpose of this particular  meeting is to choose a theme for the picnic outing.

This part is simple enough. But then, you go around the room and ask everyone to  share their specific role related to today’s meeting. Now it gets trickier.

One person may have been part of the planning committee of past events and is there to bring their experience. Another person from HR and 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, or prevent a ‘dominator’ from interrupting by explaining that “Jerry from HR” needs to chime in on any concerns from their role’s view.

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 are at a whiteboard or easel, recording decisions or helping others capture ideas. The idea is that while you ares tanding up front,  the room of four to 12 folks are the working team.

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 at one point, things are getting off track or out of hand, or if the energy is getting low, I will stand up out of my chair and show my intent to start facilitating. I usually do this by raising a question.

This seems like a very small tactic, almost making you think, “Bob – are you serious?”  But 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. (To understand the importance of energy and rhythm, be sure to read my previous post on the role of facilitators.)

What has helped you facilitate more effectively?

These are just two ideas that I have seen effective facilitators take advantage of.  While there are other techniques I may share in future posts, I love to learn and hear about other approaches.  What are some of the effective tricks you have used to help lead and facilitate your team meetings?

IT as Great Facilitators Part 1

IT-as-Great-FacilitatorsIn 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 and manage in order to be effective? 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 Bob, this is obvious. Of course I am an effective facilitator.” But let’s really test how effective each of us really are.

 

The Two Extremes of Ineffective Facilitation

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

On one side, a facilitator may go into “presenter” mode.  Although their role is to facilitate a discussion (e.g. illicit requirements from business users or help a team arrive at estimates), the “Presenter” actually comes 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 and meeting-minutes but do not influence the dialogue.  This often allows others in the meeting to go off topic and start discussing points not related, in any way, 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.

The Responsibility of a Facilitator

The best facilitators enable others to define, own and work in order to achieve their objectives. While the facilitator may bring an approach,  the solution is owned by the individuals they are facilitating.

A Good Facilitator:

  • Helps the team clarify and align on their objective and then facilitates the team so they make progress towards their objective.
  • Helps keep the group’s energy high, so everyone is contributing and feeling heard.
  • Keeps momentum or rhythm flowing towards the objective.
  • Does not change the team objective during facilitation. (Although they can help the team  change direction if the team believes it is required.)
  • Helps an entire group make progress towards its objective and makes sure everyone’s  opinion counts.

Additionally, a good facilitator is constantly taking the group’s temperature in terms of:

  • Energy in the room: Everyone is engaged, participating and making constant progress towards accomplishing their objective.
  • Rhythm of dialogue: The dialogue is flowing but stays focused on the initial goal of the meeting.
  • Focus: The meeting is staying on track and accomplishing its objective.  This 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. 

 

Are You an Efficient Facilitator?

Even if we  believe we are doing an effective job at facilitating, we may actually be playing a Presenter or even Scribe.  Here are 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, and no one’s idea’s are 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 and are an effective facilitator.

Do you consider yourself an efficient facilitator? Are there any other suggestions you can offer to help others meet their objectives?