, , ,

Being a Minimalist - Minimal Viable People

, , ,
Business Analysis Training - Minimal Viable People

As business analysts we deal with meetings, meetings and more meetings.  We are in a constant state of moving towards a common understanding of a project, system, process or outcome.  It seems like meetings get out of control with more and more people being added to the invitee list.  Nobody ever made a decision with a 100 people in a room all trying to put in their 2 cents.  It’s just chaos and a decision simply can’t be reached.  The group of 100 walks away feeling the entire meeting was completely out of control and of little value.  As business analysts we face the question when setting up a meeting for discussion or decisions: “Who really needs to be here?  Who has the power to make the decision?”.  Good communication and effective meetings require those questions to be asked but that invitee list could wind up being hundreds of people in a large organization.  If you are looking for a specific decision to be made on a specific issue or capability, then getting the meeting down to a small core team is important in order to ensure the decision is being made quickly.  This is where Minimally Viable People comes into the picture.  Minimally Viable People is the concept that a small group performs better by making decisions with higher quality while being representative of the larger group.  It also means the smaller group needs to be representational of the larger group without bias.  (Check out “Is bias destroying our decisions?)

Recently I was working with a client that was putting in a new system for their customer service team.  During the project kickoff meeting with sponsor we started to lay out a path of tasks to start up the project.  “We really need a meeting to plan the kickoff meeting”, the project manager indicated.  “I think we need a different meeting on picking stakeholders for the kickoff first then have the planning meeting before we have the kick off meeting”.  The sponsor chimed in, “I’ll need a meeting with my colleagues first, then we can meet to pick the stakeholders and then meet to plan the kickoff meeting and then have the kickoff meeting”.  As the meeting went on the number of meetings and people involved in those meetings grew dramatically.  The question asked was “Why does this person need to be there?”  The response was, “Well they need to be informed.”  The next question was, “Do they have the authority to make a decision?”  “Not really as they don’t have any resources that are working on the project.” Was the response.  So I asked, “Why not just informally let them know the project is starting instead of inviting them to the kickoff meeting and letting them know they can contact us if they have questions?”  “Well they would feel as though they were slighted and being kept out of the loop.”, the project manager replied.

Eventually we agreed upon the approach of meeting separately with non-decision makers (those that needed to be informed) either in hallway conversations, lunches or informal meetings.  For those directly involved and had the authority to make a decision either on design or resources for the project, we conducted a simple high level project kickoff meeting with about 12 managers and stakeholders.  We were quickly aligned with the project direction and outcomes.

Remember those Tuckman’s stages of group development?  Form – Storm – Norm – Perform.  I’m sure you’ve heard them over and over.  Studies show that the larger the team the longer it takes to move the team through these stages to get to performing and in a few cases the team never gets to normalize or perform.  Team’s that can’t get to the Norm or Perform stage are difficult to work with and a common understanding is out of reach. The larger the group the longer it will take for the group to understand project outcomes or make a decision.  Rumors run fast, free and wild in larger groups.  The effort to communicate and keep everyone on the same page becomes significant.  

Team Size Hurts Quality

A study released in 2005 by Quantitative Software Management (QSM) on software projects showed that, assigning a large team on software projects does not necessarily result in any significant shortening of the project time. It can actually result in more defects!  (By large teams they mean teams containing 20 or more individuals and small teams are those with 5 or less individuals).

The outcome of the study is basically larger teams make decisions with less quality then those of smaller teams for software development.  I would argue the same to be true of any type of decision.  So why do we use larger teams to ensure quality?  Perspective of course.  Could perspective be achieved in other ways?  A smaller team being more repren

Bigger Isn’t Better

According to author Stephen Robbins, when teams have more than 10-12 people, the team finds interaction and communication difficult.  The more people on the team requires a greater number of communication channels.  Mutual accountability and cohesiveness of the team more difficult in large teams. The ability to the team to “perform” suffers.  Remember the agile manifesto?  They got it right, smaller teams can perform better.  The caveat I would add is the team is representational of the larger organization.

Small Attitude

Research on top management teams, by Katzenbach and Smith, shows that small teams are far more difficult to “form” and are more likely to “storm” more but small teams fare better in the long run.  As far as the success and performance of top management teams goes, it is the quality, capability and attitude of each member of the executive team that counts.  The same can be held true with all types of teams from software development to board of directors.  Small attitude or the attitude that is positive and empowered performs better as a team.  A small team with a positive attitude produces better results then a small team without a positive attitude.  Choosing the members of a team are important to it’s performance.  Look for people that are highly engaged and positive for the team.

Agile Manifesto

Even in the world of Agile smaller teams are preferred.  Small co-located teams are advocated to perform development more effectively and efficiently.  Take a look at the role of Product Manager.  Representational of a larger groups vision, concerns and ideas?  You betcha.  The product manager represents the larger business organization in the agile team. 

Large Group Think

According to management consultant Kal Bishop, who studies ‘creativity management’, larger teams encounter Group Think.  Group think is where team members tend to lean towards consensus rather than exploration of diverse ideas.  Nobody wants to ruffle feathers in a large group so they avoid it thus avoiding becoming the group scapegoat.  The more official definition of group think according to Wikipedia:

“Group Think occurs when a group values harmony and coherence over accurate analysis and critical evaluation. It causes individual members of the group to unquestioningly follow the word of the leader and it strongly discourages any disagreement with the consensus.”

With Group Think in high gear the loudest voice gains great influence.  Diverse ideas are eliminated regardless of the quality or viability of the idea.  Ideas are not logically considered or vetted.   People begin to actively suppress those with different perspectives and viewpoints.  It’s a dangerous situation that leads to very narrow thinking.  The “Bully in the Room” significantly overrates their abilities in decision-making, and inflates their position without consideration of others.  This produces dehumanizing actions against those that are not in alignment with their position.  The good news here is that in smaller groups tends to be less tolerant of Group Think.  We’ve all had the bully in the room, but smaller teams naturally feel they can confront or disagree.  The pressure to not cause waves is reduced which is another plus for small teams!

Why the Crowd Isn’t Always Right

A few years ago the biggest hot stock tip was the Facebook IPO.  To be sure, a new offering from such a well known company is very tempting.  You feel happy and confident those dollars will be rolling in because you are following the crowd - and of course the crowd is always right.  Group think continues to feed the crowd.  Crowds tend to feed themselves and reinforce their own convictions – forgetting that the stock market is risky and profits are short-lived.  Following the crowd doesn’t always work out so diverse points and broad perspective are needed.

Sometimes Good – Sometimes Bad

The TV game show “Who wants to be a millionaire?” was an interesting example of how crowds can make decisions.  Each contestant had 3 life lines to use when a question came up they didn’t know how to answer.  On of those life lines was “ask the audience”.  The audience was right many times but as the questions got more difficult and complex they became less helpful and sometimes outright wrong.  Trick questions with answers that sound appealing were the audience’s downfall every time.  Since there was no critical voice to be heard, they could be fooled easily.  I don’t think for a second the show’s producers were not aware of that fact.

Crowds can often get it right.  For example, crowds are famously skilled at guessing how many jelly beans fill a jar, or how much a large animal weighs.  If you average their responses, the over estimates and under estimates cancel each other out and you're left with a surprisingly accurate count of jelly beans.  Taking the pulse of the large organization is important – being fully aware of group think is important too.  It’s good to know when a crowd works best at making a decisions and when it does not.  Crowds to better with simple decisions to issues that are widely understood.

Being Minimalist

Smaller teams produce better higher quality decisions and outcomes provided they are representational in nature and consider the larger groups broader perspective.  Smaller teams can avoid the Bully in the Room in most cases and get to a performing stage in Tuckerman’s model much faster.  Keep it small – keep it broad.

Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today.

References: