Tag: Facilitation

Faultless Facilitation – Leveraging De Bono’s Six Thinking Hats

Written by Robert Galen on August 22, 2011. Posted in Articles.

BA’s guiding, challenging, soft and squishy, crucial, and team-based conversations

De Bono’s Six Thinking Hats

In my last post on facilitation, I shared some general principles for facilitating technical outcomes in software teams. Much of the focus was on creating just the right atmosphere so that team members shared their opinions and made thoughtful, team-based decisions.

In this post, I want to share Edward De Bono’s Six Thinking Hats model and how it can help you in facilitating much richer discussions surrounding your technical decision-making. But first, I want to share another facilitative model with you, though it’s more of a dynamic that occurs between individuals and teams who are trying to create new products, solve new problems, add features, or generally compete in their respective markets with creative solutions that drive customer value.

Divergent vs. Convergent Thinking

Divergent – many possible answers

Convergent – one answer

One way to think about any team-based discussion that needs to lead towards a decision is that it occurs in two phases. The first phase is focused on divergent thinking. In divergent thinking, you want to get ideas on the table, so consider this team-level process as equivalent to brainstorming.

When brainstorming, you want to get ideas and options on the table. You don’t want to judge, prioritize or analyze them. You simply want to generate as many as possible. If your divergent timeframe is too limited then team members will feel as if they haven’t had a fair sharing or vetting of their ideas.

As a facilitator, letting a team ramble on or throw around crazy ideas is a perfectly sound thing to do. In fact, if you don’t do it, it will lead to less buy-in and less permanent decisions. Quite often, you’ll want to leave half of your meeting time-box for divergent conversation in order to foster engagement across the entire team.

Then, mid-way through the meeting, you need to turn the discussions around and focus more on convergent thinking. That is, you want the team to start winnowing down ideas and converging on a single decision or at least a very small subset of options to decide upon later.

If you recall, I presented some decision-making tools in my last post. For example, as part of closing down or converging on an option, you could do some of the following:

Vote on the options on the table; define loose, strong or unanimous majority before voting.
Prioritize the options, keeping the top 2-3 in play for a second round of discussion.
List pros/cons for each option, leading towards prioritization and elimination.
SWOT (Strength, Weakness, Opportunities, Threats) analysis for the top 2-3 options, then discuss and converge on a selection.
Select a decision-leader to lead the convergence discussion; if resulting discussion exceeds your time-box, decision-leader decides.

Usually, the above are led by the facilitator who is at the front of the room, actively collecting data from the team at a whiteboard or flip chart and converging towards a decision.

It’s this oscillation between divergent and convergent thinking that is the hallmark of good facilitation when making important or groundbreaking decisions. Striking the balance between over/under discussion and fostering a whole-team view is crucial. I usually allocate set times for divergent, interim, convergent, and decision-making close as part of this exercise, even allowing these themes to cross over multiple meetings.

Now that I’ve set the stage for this process, let’s move back to the thinking hats…

Back to the Thinking Hats

So what does this notion by De Bono have to do with team facilitation, and in particular, technical team-based decision-making?

Depth to our decisions

First, it gives us a breadth of perspectives to examine our options. For example, the White Hat is the data, facts and figures hat. If we were making a decision on database architecture to support our performance needs, it would be incredibly important for someone on the team to adopt the White Hat and mine the team (and customers, stakeholders and analysts) for performance-specific targets that are required for the architecture. In this case, hand-waving and conjecture isn’t helpful. What’s necessary is hard numbers and targets, something the White Hat perspective would foster and drive towards specifics.

Breadth or perspective to our decisions

As we’re reviewing and discussing something as a team, quite often we focus on a single or small set of the hats. For example, the Green and Yellow Hats often begin the discussion of new ideas or approaches for a specific design or architectural element, with Green driving the creative ideation part and Yellow the logic and positive part of the approach. If these two are the only hats that drive a decision, then the team missed four other perspectives in making their choice.

While this might not lead to a bad choice, the result will be narrowly conceived and narrowly considered. If someone on the team played the part of Devil’s advocate then they put on the Black Hat to consider some of the negative possibilities that could result from the decision. They criticized major and even minor points, trying to get everyone to consider this perspective and then respond with alterations or alternatives to the original design.

I like to think of each hat as testing the steel of an approach—tempering it and making it stronger. The more hats you use in your facilitation (divergent discussion, convergent discussion and decision-making), the broader your view is towards the problem and the broader your solutions.

Team-based influence

Quite often it’s difficult for some team members to raise issues in public. This is particularly evident in teams with strong personalities. Often, if a strong team member brings up an idea, say a Green Hat idea, many on the team will feel too intimidated to play Devil’s advocate or bring up any criticism because of the Green Hat member’s position in the team, their authority or their strength of personality.

The hats can actually dilute the personal nature of the commentary in these situations in that you’re not attacking the individual or their idea, but are simply putting on a hat and trying to fulfill its purpose. It abstracts individuals from personal engagement and quite often it strengthens their ability to bring out alternative positions that they would normally not be willing to do.

In practice, you see team members engaging the hats in this way. For example, if someone wants to bring up a criticism, they’d say, “as a Black Hat, I think the design lacks fault tolerance in the back end because of the limitations of the message-broker we’ve chosen…,” which challenges the idea and clearly not the individual.

The hats themselves

The hats often lend themselves to a flow of discussion. I’ve laid that flow out below in the order in which I present the hats themselves. Not that you have to precisely follow this flow, but it does have a sense of symmetry to it as you’ll see after going through it.

While I do recommend that you try and engage all of the hats, there are no Six Thinking Hat police that will come into your meeting, declare a violation and haul you away. Trust your team and use your best judgment in determining which hats are appropriate for a specific decision.

White Hat

Objectives; Facts; Requirements

Quite often, laying out the facts will help drive team decisions. In software, this often takes the form of requirements, use cases or user stories. White Hat discussion usually occurs in the beginning and rarely needs to be initiated. However, part of the hat is going back to the facts and refining them. In the case of functional requirements, perhaps look for tradeoffs and phasing to meet customers’ key goals.

Green Hat

Creative; Ideas

This is truly the brainstorming hat. In agile teams, this is the predominant hat, as the team works to be inclusive, respectful and attempts to get all viable ideas on the table. It’s the essence of planning and value poker as well where you get the teams’ opinions out in the open to drive discussion. This is also the creative hat, where different ideas aggregate into more creative solutions—the more the merrier.

Yellow Hat

Positive; Benefits

To use a common use case term, this is the “happy path” case for the requirement or the design that reflects the easiest implementation or has the greatest potential on the surface. It’s a great hat to explore early to gain momentum in your divergent thinking as many options will often surface for more analysis. The other side of this hat is exploring the benefit or potential of the idea—it’s business case or ROI.

Black Hat

Negative; Criticism

As I mentioned earlier in the post, the Black Hat or Devil’s advocate perspective can be incredibly useful in honing your designs and solutions. It usually refines the Yellow Hat perspective in the edge cases, creating a more robust, and error- and fault-tolerant solution. It’s also one of the most familiar of the hats for the team to leverage.

Red Hat

Emotional; Reactions

Quite often in software it’s not the logical flow that attracts customers or gets them excited. Usually, it’s something emotional or unexpected. The Red Hat is the one that reminds you to do customer focus groups and to do research within your U/X team so that you focus on those “delighters” that excite and gain an emotional reaction from your customers. It also exemplifies your gut feelings when making decisions.

Blue Hat

Rational; Conclusions

This is the decision process hat, so the facilitator often wears this hat by default. It also focuses on documentation, maintaining roles and responsibilities, and driving the teams towards conclusions. In the case of roles, this hat holds the team responsible for the role of who is responsible for architectural decisions, perhaps an architect or team leader, and who can weigh in with alternatives.

Wrapping Up

I hope you found this post and its predecessor useful. I also hope they inspire you to work on your facilitation skills—particularly if you’re part of an agile team. Why? Because many teams spin and spin around discussions and desperately need quality facilitation. I hope you can broaden your role to help fill this need.

I’ve found that Edward De Bono’s Six Thinking Hats model can truly help your facilitation within your teams by fostering depth and breadth in your decision-making. For now, I sincerely hope your decisions improve in their quality!

Don’t forget to leave your comments below.

History Repeats Itself, But It Doesn’t Have To!

Written by Paula Bell on July 25, 2011. Posted in Articles. 1 Comment on History Repeats Itself, But It Doesn’t Have To!

Why does it take an ‘Act of Congress’ for some organizations to realize that what they are doing is not working? I have been in many industries (media, manufacturing, financial and the judicial system) and no matter what industry I’ve been in, I’ve seen some of the same themes. I’ve come to realize that common sense is not that common and some organizations would prefer, for whatever reason, to continue to do things the same way even though it has been proven that the current way DOES NOT work. So you may ask, “What are some of the common themes that I’ve seen?” Well, I’m here to tell you and I’m sure some of you are experiencing, or have experienced, the same thing. I am not pinpointing any industry over another.

No time for planning – What I have witnessed is that someone comes up with a great project idea; however, no one wants to spend the time needed to effectively plan the initiative and truly understand what the initiative is about. There is an expectation that the idea will go from an idea to a reality in an unrealistic timeline. Someone of influence in the organization has committed to an objective without consulting those that will have to bring this idea to fruition. Then when the project team advises that the timeline is unrealistic as they start to look more into what is being asked for, they are told to make it happen because the promise has already been made. In a lot of these cases, the amount of resources needed to complete the project effectively is under estimated, if even committed, and this means burnout for those few who will have to work on the project.
Choosing solutions before understanding the business needs – Let’s take this one step further. Most organizations have vendors that they have built relationships with over the years. What I have found is that “someone of influence” in the organization has a vested interest in maintaining a certain vendor relationship. This maintenance could be because they are the more cost-effective vendor (this doesn’t mean they have delivered projects successfully by any means), personal relationships that have been established over the years (you rub my back and I’ll rub yours sort of thing) or other reasons. This particular individual has been sold on an idea regarding some additional functionality that the organization can possibly use, conversations occur and the vendor makes commitments without truly understanding what is needed. This “someone of influence” sells how this particular vendor can solve all of the needs of the organization, and since this someone of influence has credibility, they are told to go forward with their suggestion. This project is then funneled down to the project team, who finds out the exact depth of what is being asked of the solution, people start having heart attacks, aneurisms and heart burn because it is determined the system won’t meet the business need. So instead of the requirements driving the solution, the solution is driving the requirements.
Politics – Politics to me equals personal agendas and ulterior motives. I have not come across an industry in which I worked yet that didn’t have some level of politics. We have projects that evolve and people have their stake in the projects, which is to be expected, and that is why we have stakeholders. However, that doesn’t mean bring in your own personal agendas or ulterior motives to bring unnecessary negative energy to the project. Half the time politics is a waste of time. Projects are hard enough so why complicate it with politics? It’s a waste of energy and that energy could be utilized positively to build better solutions opposed to fighting among ourselves and everyone getting so frustrated or focused on the politics that work can’t get done. There are realistic reasons to have hard conversations to build better solutions, but I’ve actually been in elicitation sessions where I have individuals intentionally throwing wrenches into the project process because they may feel they are not getting their way. I’ve seen people trying to save their job so they make things more complicated on the project than it really needs to be. I’ve also seen the business; project team and technology teams point fingers to ensure neither look bad in front of the sponsors. All of this is a waste of energy because no one knows the future, and believe it or not, maybe the way you present yourself in these meetings may save your job if you have a fear of losing it.
Lack of honesty and integrity – People are not stupid. If the project that is being executed is going to eliminate jobs, people tend to figure that out during the requirements elicitation phase. I have had SMEs admit to me that based on the requirements being gathered, they can tell that the system will replace their job. I’m by no means saying you shouldn’t be sensitive to the situation and handle the business partners with care, but I have been[G1] parts of organizations that just flat out lie to people to ensure they get what is needed for project success (because they have to look good of course) and then these same individuals are kicked to the curb as if they weren’t even valued when the project ends. This also puts those who are part of the project team in a bad and uncomfortable position.
Lack of learning – Every organization that I have been a part of has conducted a ‘lessons learned’ session after the entire project is complete or during project phases along the way. I am convinced that some of these organizations only conduct these to mark a task complete on the project schedule because nothing has changed from the way projects are run going forward.

Despite all of this, I do believe there is still hope and that business analysts are important to this hope. There are some steps we can take to mitigate what is listed above:

Plan upfront – Planning upfront is CRUCIAL to project success. This doesn’t matter if you are using a plan-driven approach (i.e., waterfall) or change-driven approach (i.e., agile); regardless, there needs to be some level of planning. Spend the time upfront to really understand what is needed opposed to doing little work and then realizing two months in that instead of a bread box of a project you have a submarine of a project. Utilize the business analysts in the organization to help with planning upfront. Good business analysts are equipped to do Enterprise Analysis (higher-level statements of the goals, objectives or needs of the enterprise) in addition to Requirements Analysis (statements of the needs of a particular stakeholder or class of stakeholders). Engage the business analyst upfront to have some of those critical conversations opposed to just filling out a template with a high-level scope that is so broad that almost anything can go into it producing your submarine opposed to your bread box.
Don’t jump the gun –- Opposed to choosing solutions due to past relationships or other reasons, again, leverage the business analyst to understand the true business need so the needs drive the solution opposed to the solution driving the requirements, which in turn limits the true needs of the business. I would strongly recommend that leaders of the organization go out onto the floor and meet with those that actually do the work to find out the true pain points they encounter day in and day out. Just because you are a leader, don’t get too disengaged from what is going on within your organization. I know this can be as challenging as schedules, but there is value in staying connected with those who are actually doing the work. If anyone understands the pain of the system or process, it’s the one using the actual system or process, so don’t take that for granted. This is also a great opportunity to leverage the business analyst as well. Maybe have the business analyst do some job shadowing as part of their planning to understand truly what the needs are. This will help leaders make more informed decisions.
Channel positive energy – Let’s take energy away from politics and channel that energy to producing better solutions. There are crucial conversations that may need to take place and hard conversations to be had, but those conversations should occur for the benefit of the project not because of someone’s ulterior motives and personal agendas. When a project is created, the end goal of everyone on the project team should be project success.
Don’t compromise – Character is the very fabric of who we are, and if we lose our character because of dishonesty or lack of integrity then how are we going to gain that credibility needed to become a person of influence, if you are not one yet, or a credible leader to those you lead? Be sensitive to projects that are eliminating jobs as you are impacting someone’s life, but don’t lose your credibility in the process. Fellow business analysts don’t fall into the trap of having to lie to do your job. In all things, be honest and kind. Don’t compromise your character to get your job done because sometimes we are put in that position. Once you compromise that you are compromising the business analysis profession based on perception.[G2]
Learn from your past – If you are going to do lessons learned then truly learn from them. If anything, to my fellow business analysts, learn what went well and what didn’t go well in requirements gathering and use that as your thermometer for other projects. Everyone on the project team should learn from the past, but if no one else does, business analysts I really encourage you to learn from your mistakes because this makes you a stronger business analyst.

With the themes above, someone of influence is driving the actual theme whether positive or negative. As business analysts, it is imperative we become someone of influence in our organization. This is not going to happen without credibility and proven success on projects, and I will be honest, even with this, sometimes it’s hard to influence due to company structure. However, if you take time to learn your organization’s culture, learn the key players in your organization, establish relationships where you can to start gaining credibility, you will become that someone of influence in the organization. We need more business analysts to be leaders and people of influence in the organization because we have the skill set to promote organizational cultural shifts that will make the organization stronger and better. Changing an organization’s culture can be extremely difficult; look at organizations that had to change from a waterfall methodology to an iterative methodology and the pain that came with that.

And for those business analysts that are consultants/contractors, you have a very important role as well because you can help organizations reach their optimal potential. Though you may be there for a temporary amount of time, you can still have massive impact on the organization as a whole.

Don’t let history repeat itself in your organization because it doesn’t have to. As business analysts, we have come too far to go backwards now. Keep pushing forward and help organizations realize the benefits business analysts bring to the organization.

Don’t forget to leave your comments below.

Paula Bell is a Business Analyst, mentor and coach known for consistently producing exceptional work, providing guidance to aspiring business analysts (including those that just want to sharpen their skills), as well as providing creative and strategic ways to build relationships for successful projects. With 14 years in project roles to include business analyst, requirements manager, technical writer, project manager, developer, test lead and implementation lead, Paula has experience in a variety of industries including media, courts, carpet manufacturing, banking and mortgage. Paula has had the opportunity to speak on a variety of topics to include business analysis, project management, relationship building, diversity and software methodology.

Faultless Facilitation – The Art of Team-Based Decisions

Written by Robert Galen on June 27, 2011. Posted in Articles.

Business Analyst’s guiding challenging, soft & squishy, crucial, and team-based conversations

Nowadays, I spend 100% of my time in agile teams either engaged in direct coaching, teaching, or participating directly within the team. One of the core tenets of agile teams is self-direction. This is a state that is much easier to say than it is to achieve. One of the more critical activities that fosters self-direction is effective facilitation and the role of facilitator.

Leveraging Scrum then, this ‘art’ largely falls within the realm of the Scrum Master. A large part of that role is directed towards focusing the teams’ energy on effective discussion, debate, and decision-making. Trying to create an environment where the team experiences what Jim Surowiecki calls The Wisdom of Crowds. The key point is that the collective wisdom of a team, group or crowd is quite often greater and more valuable than any singular domain expert.

These team-based innovative solutions surround architectural & design choices, surfacing and analyzing critical customer requirements, and crafting the simplest yet most powerful feature sets in response. There are often a myriad of directions or choices a team can make and getting the path right isn’t always easy. Effective facilitation can be one of the differentiators for teams hovering between average and outstanding delivery.

5 Dysfunctions – The Passionate Debate…

As it turns out, technologists seem to debate everything. Or at least that is my experience from over 30 years of software development. They’ll be just as passionate about naming conventions for a particular nondescript configuration file as they are about designing a high performance databases for a new large-scale CRM application.

I think it might have something to do with personality type or perhaps just a fondness for debate. Regardless, just as we have a tendency to be overly optimistic with respect to estimates, we have a tendency to deaden the horse on nearly all technical topics.

I recently read The Five Dysfunctions of a Team by Patrick Lencioni and received some excellent training surrounding that material. One of the key points the instructor made focused towards encouraging teams to have Passionate Debate…but about the Things That Truly Matter. It’s the last part that we often forget as technologists.

A good facilitator will try and focus the discussion away from the myriad and towards the things that truly matter. It’s a prioritization game that aligns incredibly nicely with the agile methods.

So what does this have to do with BA’s?

If you’ve read any of my posts about agile and BA’s, you’ve seen me continuously reframing your role—for example, from an early requirement provider, to a whole-project oracle for requirements and their evolution. Or reframing towards establishing an ongoing and intimate partnership with your customers.

In this post, I’m trying to influence your facilitation skills. I think most BA’s have a wonderful capacity to facilitate team-based discussions surrounding requirements. But I feel you can extend that towards general facilitation surrounding all aspects of an agile team attacking a project. It’s this extension that I hope you entertain.

A Quick List of Facilitation Tools & Techniques

So, if you’re a BA who wants to improve your facilitation skills, I thought I’d provide a list of some techniques that I’ve found helpful in guiding teams’ towards successful agile execution. While these tools and techniques can be helpful in all contexts, I feel they’re particularly helpful in agile contexts. Enjoy!

Ask why; ask why five times

There is something quite powerful about asking why. Why are we doing this? Why is this complex design the only way to solve this problem? Why are we taking on so much scope in delivering this feature?

In lean circles a common approach is to ask why five times. The tactic is to peel the onion and drill through peripheral points into the core of an issue or requirement. And when you ask why, don’t be afraid to wait for an answer. Allow time for folks to think about the question and respond. Sometimes that silent pause can be most helpful in getting to the essential core of a discussion.

Ask silly questions

One of my favorite approaches to foster expanded discussion is to ask silly or frivolous questions. Sort of putting myself out there as being clueless, so that others will seize the moment to correct me and explain the options, true nature of each, and why we’ve chosen the direction we’re taking.

The other side effect is that teams’ will also re-examine their drivers for a decision and often look for simpler approaches. It sort of shocks their nervous systems into reconsideration. But clearly you need a thick skin and self-confidence to take this approach.

Make controversial statements – see who responds and how

A variation on the silly question approach is to make absolute or other controversial statements. Let me give you an example. In your business domain, designing and testing for high security is an important criteria.

So in a requirement planning session you exaggerate as to how little security testing you’ve seen in the requirements—knowing that there is a reasonable level. You’re looking for team members to respond with the facts. You’re also looking for realization across the team of any security testing ‘gaps’ that might still exist.

Put on a different hat (Development, Sales, Marketing, QA, Architecture, Regulations, PMO, Management)

One of the more powerful actions you can take is changing your point-of-view or perspective. That’s why personas are so powerful when developing User Stories. They help you to clarify the ‘User’ in the “As a _____” clause.

But you don’t need formally defined personas to put on different perspectives. Simply ask the team to consider the requirements, design, or problem from various lenses. I think the facilitative art is in selecting the perspectives based on the problem at-hand and not simply going down a by-rote list.

Devil’s Advocate

I sometimes struggle when someone adopts the Devil’s Advocate position. I’ve seen it miss-used as a stalling or blocking tactic from those who aren’t truly interested in specific directions or decisions. In these cases, it’s an unhealthy plow.

However in the healthy case, it’s a wonderful perspective. It focuses the teams’ energy on the opposite case, causing them to think about decision alternatives and how to defend & strengthen their case. Often it drives slight alternative approaches that might not have otherwise surfaced.

Recognize / thank folks that exhibit and weigh-on with candor

Actively recognizing folks who are weighing-in with valuable feedback is another way of encouraging feedback. First acknowledge those that are engaging and thank them for their contributions. If someone takes a risky position or challenges an incumbent in a courageous manner, I like to point this out as well.

In fact, the more candor I see being driven into the debate, the more I visibly appreciate and recognize it. Now you have to walk carefully here as a facilitator so you’re not perceived as picking favorites.

Exaggerate – small or large

This one of my personal favorites and I probably overuse it a bit. It’s related to the controversial statement option above. However, in this case, you minimize or maximize the point being made. It serves to get the teams’ attention and focus them on the “shades of gray” related to any discussion.

For example, if I detect that the team is minimizing the testability aspects of a design discussion, I might ask them how they’d propose testing it if they had to do it? What if they didn’t have any ‘testers’ at all? In this case, that exaggeration might pull the teams’ consideration towards the importance of building in efficient, up-front testability.

Ask quiet folks to weigh-In OR ask loud folks to weigh-In last

Team dynamics often seem to include quiet and loud characters in their fabric. Part of the role of a facilitator is to equalize these voices – in an effort to create an environment where all voices (opinions, options, thoughts) are heard.

One technique for loud voices is to privately ask them if they’re aware of how influential they are on the teams’ decisions and to ask them to weigh-in more carefully and after others have had their opportunity. For quiet members, often simply asking them directly will get them to engage.

Or assigning them a position that you think they’ll struggle with—in order to drive them from their comfort zone. Another approach is to setup ground rules that expect everyone to fairly contribute to decision-making.

Facilitative Tools

As a means of wrapping up this post, I thought I’d share some traditional facilitative tools:

Clearly rank options as a team; then converge on the best option based on team discussion – removing outliers first.
Discussion, then team voting; re-vote as required. Use a technique where you surface supportability of a decision vs. agreement with the decision.
Time-boxed discussion; then a pre-declared decision-leader decides if the team can’t come to a decision within the time-box.
List Pro / Cons and vote as a team – consensus or majority or decision-leader led decision.
Explore the overall cost of doing it vs. the opportunity cost – not doing it. Keep the discussion focused on value & cost—making it a mathematical decision of sorts.

Quite often it’s useful to write down or specifically quantify your discussions – making lists, ranking items, and generally clarifying the discussion in words at a whiteboard or on a flip chart. This has a tendency to bring the team back towards reality and help them to converge on a direction.

A large part of this is driving towards a decision—often the hardest part of facilitation. So having a variety of decision-making models can help.

Wrapping Up

I hope you found this post useful. I also hope it inspired you to work on your facilitation skills—particularly if you’re part of an agile team. Why? Because many teams spin-and-spin around discussions and desperately need quality facilitation. I hope you can broaden your role to help fill this need.

In my next post I’ll be sharing another tool for facilitation – Edward De Bono’s Six Thinking Hats model and how it can also help your facilitation. Till then, happy decisions…

Don’t forget to leave your comments below.

Common Mistakes Made By Business Analysts Playing the Role of Facilitator

Written by Greta Blash on June 14, 2011. Posted in Articles.

In Agile projects, the business analyst can elicit the business requirements more effectively by facilitating the meeting rather than interviewing stakeholders individually. Here are some of the common problems that a BA can encounter.

Problems in the Meeting

Failure to Relate to Participants: This is the most commonly mistake made by the facilitator and is usually caused when the facilitator has not prepared for the meeting by reviewing the background of the participants and categorizing them. Each participant has a different background and different characteristics. The facilitator cannot treat the participants the same or as a generic person.

Failure to focus on the Meeting Content: When too much information is being exchanged during the dialogue of the group, it becomes difficult to direct the participants to focus on the key point of the discussion. The facilitator must identify key words for each point as a summary of the content to help visualize the discussion. If this is not done the team may become frustrated, especially if the discussion is going around and around resulting in a state of confusion. The facilitator must identify each point, capture it, organize it, synthesize it and clearly document it. People expect the meeting process to be well managed and these steps will help meet that expectation.

Failure to Use Group Memory: People can only tolerate so much pure discussion without having something written down. If the facilitator encourages discussion and listening without writing anything down, participants may begin to feel that this is a just an informal discussion. Facilitators must create or reference visual memory at least every fifteen minutes. As the meeting proceeds, the amount of written documentation will continue to grow. It is also important to make use of any support materials before, during or after the meeting. Remember that written words, and diagrams, are more memorable than spoken words.

Problems with Participants

There may be minor problems with some of the participants during a session. However, there may be some serious problems with an individual participant that can impact the entire team. So let me explain what I have encountered.

Blue-Sky: Blue-Sky participants are progressive and optimistic people who believe they can accomplish complex tasks. They tend to view their objective as part of the group as a mission to seek out new information, to discover new ways of doing business and to venture where no other team has ventured before. This type of person wants to take on as much as possible, to change as much as possible and to totally re‑engineer the business often using new and advanced technology. The problem is that the organization may not be ready for such drastic changes. The intent of this type of participants is good but the facilitator must rein in this person by directing questions to all of the other participants. The facilitator should determine if the ideas in the discussion are realistic and achievable within the boundaries and the budget of the project scope. The facilitator should involve the team in determining the direction of the conversation rather than trying to cut off the discussion point.

Snowball: This type of participants likes to continually add one more item to the discussion. They usually say, “While we are doing that, let’s also do this…” The difference between a blue sky and a snow ball participant is that the blue sky participant will talk about doing everything at once, while the snow ball participant adds one thing at a time. This technique can add quite a bit to the discussion points over the course of the meeting. The facilitator needs to recognize that the added item identified in this manner is not directly part of the effort. The facilitator should validate with the group if the discussion point is within the team’s scope and a part of the team’s objectives.

Wanderers: This type of participant likes to meander during their discussion point or talk about something that is not related to the topic nor follows the dialogue that was in progress. Wanderers enjoy tangents and digressions. They tend to begin to speak before they have thought out their ideas. The facilitator must stop the wanderer before too much time has been wasted and/or as soon as the facilitator recognizes that the discussion point is not relevant to the topic. The facilitator should consider if it is a digression or not in order to get back to the topic. Often these points can be put on a “parking lot” to stop the discussion and return to the points at hand.

Philosophers: This type of participant likes to inject academics into each discussion topic. This person’s language skills are advanced and often speak using a large vocabulary of difficult and often unrecognizable words. Participants who are more practical will find it difficult to work with the philosopher. The facilitator will need to rephrase, or summarize, what the philosopher has said in order for all the participants to comprehend the discussion point. The facilitator needs to verify with the group if the ideas expressed in the discussion point are practical and feasible for the organization. The facilitator must not allow the philosopher to carry‑on without the idea being documented in the group memory.

Conversers: These participants are usually more social and tend to seek out other participants who share the same characteristics. Most of the ideas they express are not related directly to the topic, although it may appear that way as they begin their discussion. They are similar to the wanderer, who also like tangents and digressions. However, they are not as far off from the topics as the wanderers are. The facilitator needs to listen to the converser’s idea, assess if it relates to the topic and limit that person’s time to speak. The facilitator should determine their ideas are a part of the topic or relate to something else. The facilitator must monitor this person’s contributions more closely than others in order to keep the other participants from becoming frustrated with what appears to be unnecessary and time wasting discussions.

Devil’s Advocates: This person is always negative when expressing their ideas. They tend to state that things will never work, that things can’t be done or that the technology is too complex. These pessimistic people can become a real downer to the other participants because they will be viewed as being against the rest of the team. The facilitator must request that this person keeps an open mind to the ideas that are expressed and only when there is a negative aspect that others haven’t identified, should they point this aspect out. This type of person can become very harmful to the overall team’s motivation. Too much negativism can turn the meeting process into a frustrating experience for all participants.

Followers: These people like to follow the lead of the others, especially others from their own department. They always align themselves with their manager or an influential person in the group. They are always in agreement with that person and are reluctant to express their personal view. This may be due to previous experiences when having been in meetings with their manager or this influential person. The facilitator needs to recognize that this person is continually repeating what others have said and should try to ask a specific question that will enable them to express what they really feel about the topic. The facilitator may need to stand between the follower and his/her manager to block his/her view.

I have only listed a few problems that I have experienced for this article and I would be interested in some the problems that you had endured – so please feel free to leave your comments or contact me directly.

Don’t forget to leave your comments below.

Steve Blash is an experienced IT professional consultant providing business and technology leadership, mentoring and vision. His areas of experience include business process improvement, business analysis, business intelligence, data analytics, project and IT management.

Amplifying Collaboration with Guerilla Facilitation

Written by Ellen Gottesdiener on March 15, 2011. Posted in Articles. 1 Comment on Amplifying Collaboration with Guerilla Facilitation

Do you ever feel frustrated that you can’t intervene during group gatherings gone astray? How can you take action when you’re not the one in charge? Do you wondering how you can “lead from behind” to improve the quality of your community collaboration?

Here are some suggestions for making meetings or work sessions work better for everyone.

The Writing on the Wall

We humans first communicated with each other on cave walls. Making your content visible on walls for everyone to see and react to is probably one of the most powerful ways for groups to communicate. You can take advantage of this strong visual orientation by becoming the group’s recorder. In this way, you can assist the facilitator (and perhaps act as co-facilitator).

To take this action, be prepared with flipchart paper, wall-friendly tape, and markers. At the meeting, record key summary points, decisions, actions, and a parking lot, perhaps on separate posters. (The parking lot is a place to store topics you want to cover later.) Be sure you honor people’s words. Don’t paraphrase without getting permission.

At the same time, you can facilitate the discussion by checking in with the group on anything you write. Here some examples of questions you should ask:

“So can I summarize that by writing . . .?”
“Can I capture that idea by writing . . .?”
“Looking at what I just wrote, does that summarize your point?”
“Can you headline that so I can capture it on our poster?”

Depending on your relationship with the facilitator or meeting leader, you might ask permission to do this ahead of time. Or you might turn to the meeting leader (if there is one) and ask whether it’s OK for you to record key points from the session.

Do You See What I See?

One of my most profound learning experiences as a facilitator was the time I acted as an observer rather than a participant or a facilitator. (My mentor suggested I do this because I felt lost not being in the role of the facilitator!)

Being an observer forced me to focus strictly on studying the group dynamics, watching the flow of interactions, making a point of noticing nonverbal behavior, and sensing the ebb and flow of energy in the group. When I started to see a pattern, I then shared my observation with the group without suggestion or judgment.

For example, I would say, “I noticed when we were discussing , most people made comments and were looking at each other. But when the topic of came up, some people leaned back, others kept glancing toward the clock or door, and there seemed to be less energy in the room.”

You can transform your observations into meta-observations by inviting feedback on the observation itself. You do that by stating the observation, following it with your own inference or assumption, and then checking it out with the group. For example, you could say, “When we were discussing , I noticed more people spoke up. I’m guessing that the topic of is more important to everyone than . Do I have that right?”

By noticing and pointing out specific, observable behavior, you enable the group to “process its process” (what we might call the meta-process). Most of us participate in gatherings without thinking about the group process itself, let alone how to increase its effectiveness.

Acting as an observer and sharing your observations with the group help the group to process its process and thereby improve it. These practices also increase your own skills in being a facilitator, because effective facilitators are expert observers.

Purpose, Products, and Process

If you are not the facilitator and the meeting has no agenda or stated purpose, ask for them ahead of time. If you do not get them but choose to attend anyway, interject early on by asking, “What is the expected outcome of our time together?” Help guide the answers by asking about the meeting’s purpose, products, and process.

When people begin to respond with these questions, stand up and write them on poster paper with the label “Outcomes.” If posters aren’t feasible, ask to take notes (on your laptop, if you have one with you, or by hand if not), which you’ll send out after the session.

Having the outcomes posted on the wall will keep everyone focused on what the group needs to produce. When you hear off-topic discussions, you can point to the outcomes poster and ask, “How does this discussion get us to our outcomes?”

CARES from Your Chair

You don’t have to be the facilitator to use the techniques of an effective facilitator. From where you sit, you can take specific actions to help the participants improve their process. Here are some tips, gathered under the acronym CARES (clarify, ask, reflect, explore, summarize).

Clarify: Check for understanding by asking a question such as, “So are you saying you are concerned about whether this requirements should be in scope or not?” or, “Earlier you said , and now I hear you saying, and these seem in conflict. Can you clarify that?” or simply, “Do I hear you saying . . .?”

Ask: Well-timed questions can have a powerful effect on a group process and promote shared understanding. For example, ask process questions to help redirect a group gone astray: “Is this topic relevant to achieving our planned outcome?” “Is that a topic we might put on our parking lot?” Focus questions help elicit specific information. When you ask, “What are some of the key pieces of information that are used to make that decision?” you will obtain a directed list that’s relevant to the topic at hand.

Context-free questions (Gause and Weinberg, 1989). Such as “What problem does this solve?” or “What problems could this software | process |requirement > create?” expands the community’s thinking about the nature of the project, situation, problem, solution or requirements. Reflective meta questions (Gause and Weinberg, 1989 ) promotes introspective in the group. Asking “Do the questions we’re asking about product requirements relevant?” “Are we the right people to answer these questions?” “Are there other questions we should be asking?” helps the group think about their collaborative thinking.

Reflect: Effective groups continually check on their own process. Don’t wait until the end of the meeting or session to make effective use of self-reflection. Ask, “How do you all think we are doing in making progress here today?” “Can I do a process check and ask everyone if they think we’re heading in the right direction with our time today?” “I’m curious whether this session is productive for us right now. What do you think?”

Explore: Don’t assume that everyone understands or agrees about the topic at hand. Some participants aren’t vocal, or their nonverbal behavior is ambiguous. Do their folded arms indicate contemplation or disagreement? Does foot tapping indicate impatience, anxiety or too much caffeine? Don’t guess where they stand, and don’t assume you know what they know. Ask!

Open-ended, exploratory questions probe for more information. Posing questions like, “I am curious to hear what concerns or suggestions some of the folks who haven’t chimed in yet might have. Would you share that with us?” or, “Can you explain further the impact of on our organization?” can unleash powerful information sharing.

Summarize: Accelerate the group’s process by wrapping up a topic with summary statements or questions. It also helps groups move toward closure. Start by making a statement such as, “To wrap up this discussion: everyone agrees the scope should not include , and we need to revise our scope model” or, “I hear us agreeing to ask the customer to help us develop user acceptance tests in the next iteration.”

Don’t Go

If you’ve tried these actions to no effect or have asked permission of the person in charge to do so but have been turned down, then your last resort is to not participate. In the end, we are responsible for making optimal use of our time to serve our end customers. If you can be more productive doing other work than attending an ineffective group sessions-and you have honestly explained your reasoning for not attending-you are acting in a professional manner. Indeed, your example might inspire your colleagues to follow suit.

In Sum

Collaborating teams are comprised of individuals who take personal responsibility for not just their own behavior, but also for promoting healthy collaboration of the group itself. That includes ensuring valuable use of the group’s time together. We have all heard about the staggering cost of ineffective meetings. We don’t need to be victims or contribute to the waste. If the process is not working and you’re not the designated facilitator or leader, you can still take corrective action. These suggestions are small but powerful ways to affect your project community.

Don’t forget to leave your comments below.

(This article first appeared in Sticky Minds, 2010)

Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc. She helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOK^TM agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.

References

Gause, Donald C. Gause and Gerald M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House, 1989

Gottesdiener, Ellen, Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley, 2003.

Tabaka, Jean, Collaboration Explained: Facilitation Skills for Software Project Leaders. Addison-Wesley, 2006.