Get NEAR - Reduce Communication Debt

In a recent post, I introduced the topic of Communication Debt as a pressing problem within many organizations. You might be are aware that you are suffering from communication debt, yet you may not know how to tackle it.
Here's a model to help you get a grip:

Level 1: Reasons

Very often, we encounter that people discuss the tasks they are (expected to) do, yet either fail to discuss why it is important - or use bogus reasons to avoid more time-consuming and/or meaningful discussion.

Lack of reason results in religious actions, i.e., where tasks are completed devoid of deeper meaning or with a vain hope of success. The more reason debt exists within an organization, the more work is being done where nobody can truly explain why it's done. Oddly enough, reason debt results in an insecurity of what would happen if we stopped doing it - the status quo is preserved without reason!

Level 2: Assumptions

We all make assumptions, all the time. Every decision we make is guided by our underlying assumptions. When our assumptions differ, our conclusions differ. What looks good based on assumption A might look stupid based on assumption B. Inconsistent assumptions can tear relationships - and therefore, entire organizations, apart.

For example, I might assume it's better to have one person have only one task at the same time, while another manager X might assume it's better to give multiple tasks to people in parallel. The way we would organize work within our sphere of control would vastly differ.
In my discussions with X, I might accuse him of causing overburden waste and X might accuse me of capacity waste - because we have different assumptions, which are caused by different understanding and different chains of reasoning.

Unspoken assumptions may result in an actor doing things that another person highly disagrees with. Until we communicate our fundamental assumptions and discover why we assume what we do, we will be hard-pressed to align.

Level 3: Expectations

Expectations decide whether our actions are considered "successful", and different expectations lead to different results. Misaligned expectations often result in blaming, resentment and frustration.

As a simple example: If X expects fast results, they might accept any kind of makeshift clutch as long as it somehow "works". Y might expect high aesthetics and a level of comfort. When working with X in the same way as with Y, X will be disappointed - and when working with Y in the same way as X, Y will be disappointed.

Missing the communication of expectations makes it impossible to meet them without resorting to assumptions (moving the problem to another level without solving it). Many organizations have learned to minimize expectations, because they have not learned to align them.

Level 4: Needs

Not talking about needs results in fickle, unstable relationships - yet it's often considered "unprofessional" to spend time discussing needs. This is a very odd situation, as discovering each other's needs is fundamental to relationship building and provides the basis for any kind of negotiation.

Uncommunicated needs result in misunderstood requests, while communicating needs helps build trust and understanding. This is as true for work relationships as for private relationships.
Yet, we tend to be abysmally bad at understanding each other's needs in a corporate environment.

For example, when I say "I need a hammer", this might go through demand management, order management, vendor management and purchasing - after hours of negotiation, I end up with a bargain bin sledgehammer (at an unbeatable price) - while my original intention was to fix a poster to a wall with a few thumbtacks: my problem might have been solved with a pack of blue-tack instead.
I didn't need a hammer, I needed a way to fix that poster ...

Misunderstanding needs results in a misinterpretation of expectations, we resort to (misunderstood) assumptions and we resort to (misunderstood) reasoning for our action.

Instead of fixing this kind of communication gap, people resort to abusing communication in order to create sufficient leeway so that they can meet their own needs, often to the detriment of mutual relationships.

Summary

The longer an organization exists without fixing their communication debt, the more misunderstanding about needs, expecations, assumptions and reasons exists - every day bringing people further apart.

When you want to have better communication, get NEAR. Align needs, expectations, assumptions and reasons.

Let's talk about Communication Debt

During a recent discussion on LinkedIn, one comment was made that we're talking a lot about technical debt - yet not about communication debt. While it's easy to overstretch the debt metaphor, communication debt arises frequently and it is at least as damaging as technical debt. In the best case, the debt is outright prohibitive, forcing us to deal with it immediately. In the worst case, we never get around resolving it until the problems are beyond redemption. So, let's take a look ...


Communication debt is the communication we should have had, but didn't.

Why is communication debt a problem?

Missing or misfired communication creates a situation where people who should be on a similar level aren't. Why is that even a problem? Here are some examples:

Example 1: Short-term debt
A Product Owner explains the feature that developers need to create. Developers can't help wondering what the user would want to do with this feature, as it is very similar to some existing functionality, except that it's more complicated.
Here, failure to communicate user needs and system capabilities resulted in wasted time, money and dissatisfied users.
Fast feedback loops make short-term debt is easy to discover. It is rather simple to resolve.

Example 2: Mid-term debt
A developer uses variable names that are optimized for typing effort. For instance, instead of naming the fields "invoiceTotal = netTotal  + taxAmount", the code reads "X = i+t".  This kind of code works, yet in order to work on the same code later, significant additional effort needs to be spent to decipher what the cryptic variables mean and why the program does what it's supposed to.

Example 3: Long-term debt
Tina is the corporate architect. When a new feature is requested, Tina is able to decide fast and correct which adjustments need to be made in which place of the corporate infrastructure. One day, Tina receives a good offer from a different company and leaves. When she is gone, the entire company falls into disarray, because nobody was on her level. For many months, people waste time with reverse analysis, trying to uncover what needs to be done.

The Impact of communication debt

As hinted in the examples above, the impact of communication debt may differ. Short-term debt is most likely to result in strongly felt reductions of effectivity, while long-term debt may be hidden until a crippling blow hits productivity.

Here are a few ways in which communication debt impacts you:

• Confusion about the intention of tasks
• Confusion about the purpose of things
• Wasting time acquiring existing information
• Wasting time discovering "missing links"
• Not getting things done because of lacking information
• Doing things "wrong" because of lacking information

Hints at existing communication debt

Even before you experience the impact of communication debt, you may experience hints that there may be hidden communication debt. These hints are "smoke detectors" indicating that there may be a problem:

• Intention:
• You don't get the point of the communication
• You missed the point of the communication
• You feel patronized by trivial communication
• Value:
• You feel you didn't learn anything after communicating
• The information doesn't help you further
• The information leads you in a wrong direction
• Talking:
• You think that you need to talk, but feel uneasy about it
• You feel that you're talking to each other, yet not with each other
• Conversations raise negative emotions, such as anger, indignation, contempt
• Availability:
• Discussions that should happen, don't
• Important information takes time to get
• Existing information is not available upon request


• Meetings:
• Status meetings
• Meetings which cover multiple topics at once
• High-level summary meetings with little outcome
• Attendants that can only contribute marginally
• Documentation:
• Knowledge is documented rather than conveyed face-to-face
• Things that were discussed face-to-face get documented "as proof"
• Communication happens asynchronous via documentation hand-over
• Tools:
• People use tools to avoid face-to-face conversation
• Tickets are sent among people sitting in the same office space
• Communication gets "standardized" via templates
• Complexity:
• It's difficult to discover who knows someone who has the information you need
• Information is fragmented or only partially available
• Information requires keys (meta-information) to comprehend

Summary

Years ago, I jested: "How do you know you work in Telecommunications? Because direct communication doesn't work." Communication debt is everywhere. It happens even in the commercial and social media. It can be devastating, yet few people tackle the problem.

The "4 Re of Complexity"

How to deal with complexity? Too often, I hear "But it's so complex". As sparked by another one of my recent posts about the often prematurely assumed need for tools, here is a small model how we should approach complexity:

The 4 "Re" of Complexity

The 4 "Re" of Complexity

Resist the introduction of more complexity

You should resist the temptation of introducing complexity that you neither have nor need. Additional complexity introduces risk and effort - you want neither. Simplicity requires actively struggling against complexity. Both effectiveness and efficiency require minimal complexity.

Sometimes, you just can't avoid complexity that you neither have nor want - for example, when it's forced on you by regulatory compliance. Still, you should do your best to prevent that complexity from creeping in. Try to do the absolute minimum necessary rather than see "what else might be needed".

Reduce the need for new complexity

Sometimes, you need additional complexity of some sort to work effectively. Maybe you think about automating a process? This increases your technical complexity in an effort to reduce the complexity of manual effort. That makes sense - as long as the complexity you add to increase the efficiency of one task should be lower than the complexity you are removing.
For example, if you would use an automated testing suite with maintenance effort higher than manual testing, it doesn't make sense to automate. You would be adding more complexity than you remove - a bad deal.

Remove unnecessary complexity

Complexity is like dust on a shelf. It just adds up over time until you can only fathom the thing you originally put into place. Processes are often religiously followed without an understanding of what is needed why. When you discover that you have complexity that could be abandoned without any detriment to your business outcome - do it.

Reinvent existing complexity

Do you remember the days when you wrote a letter on a typewriter, then printed it out, only to fax it? Why don't we do that any more? Because email achieves the same purpose much faster, easier and cheaper. Even complexity that exists in your environment can be scrutinized for improvement potential. Discovering completely new ways of achieving a goal with less effort is advancement. Chances are, if you found an ingenious solution, others will benefit, too.

Summary

Never be content with complexity. Finding ways of doing the same thing simpler is essential in order to not be overwhelmed. The "4 Re of Complexity" help you dealing with complexity in an effective manner.

Building a CI tool from scratch in one hour

Is a CI server the right answer for your team? Do you need a CI tool? "Well, that's obvious!". Is it? You may be surprised! 
This is a lesson I learned about the Agile Principle #10: "Simplicity - maximizing the amount of work not done - is essential." 

A simple CI chain, providing essential feedback to the developer

We need a CI tool

In most software development projects, someone will say the sentence "We need a CI server" - usually right at the start of development, before the first line of code is written. In an extreme case, a company paid many thousand Euros to set up a CI chain before any developer was using it. Tools like Jenkins, Hudson, Bamboo and the likes pop into mind right away. They are very good at what they do.

When I worked with one organization that had been using Atlassian's Bamboo from day 1, I talked to a senior developer who took personal responsibility to create the best possible CI process that developers could get. He jested that setting up a build chain in Bamboo required a master's study in Atlassian tooling.

This leads me to pose the question: "Do we need the complexity that a CI server creates to achieve the goal we want to achieve?"

CI isn't rocket science

In its simplest form, CI doesn't do more than retrieve the latest commit from the version control system, create a new build, deploy it - and run the tests. Developers are informed about the consequences of their actions, and that's it. Of course, complexity can be added as needed.

Do you really need a magnificient tool to do this? Is it worth sinking hours (or days) into configuring and maintaining a platform to do this trivial job for you?

My claim: You don't need a standard out-of-the-box CI tool!

How to create a CI tool

We were in a training setting. It was a Certified Scrum Developer course provided by Andy Schliep. It was fun and we were building a training application (real, working software!) in Ruby. Andy set a constraint for the Definition of Done "Works on this machine".
There was eight of us in the course creating Ruby code - so we needed Continuous Integration. In a training setting, we didn't have a CI server, nor the time to set one up. So, we reduced it to the essentials. "What do we really need from CI?"
A developer story was born.
Since we had a cool gadget from blink1, Andy added the Acceptance Criteria here: "The light must be red on a failed build and green on a successful build." Blink1's API is very simple, so we got going.
Even if we had used Jenkins, the integration with our blink1 USB light would still be an open point.

Since I love Shell, I started writing some Shell code to access the blink1 LED:

blink()
{
  ~/tools/blink1-tool "--$1" 2>&1 >/dev/null
}

This small function snipped would allow me to set the color of our blink1 LED to anything I wanted, for example, red, blue - or green.

The next thing I needed was the failure state:

fail()
{
  blink red
  echo "CI step failure." | log
  exit 1
}

Of course, I'd also need a success state, which looked pretty much the same.
Like that, I could already "fail the build".

We then brainstormed which activities we would need in our CI. We ended up with the following sequence of actions:

1. checkout the latest code from github
2. install the bundle
3. clean the database
4. run the tests
5. start the server

If all five activities succeeded, we would call this a successful build and "pass the build".

The main control logic of our CI looked like this:

ci_process()
{
  for task in checkout install_bundle clean_db run_tests; do
  do_task $task
  done
  ( succeed )
  do_task start_server
  }

Of course, we still needed to fill the logic for each task step, so we did that, too. Tapping into the knowledge of my teammates as to what exactly needed to be done, I wrote functions for each task as well. It looked pretty much like this:

checkout()
{
  git_feedback="`git pull`"
  echo "$git_feedback" | log
  [[ "$git_feedback" == "Already up-to-date." ]] && return 1
  return 0
}

After we had the essentials down, we started polishing the code a little, adding extra features such as turning the light blue while the build was in progress.

Everything together, we spent roughly one hour to create this "CI tool" which served it purpose. It is less than 100 lines of code and can be viewed here. Of course, I should have added unit tests - but we were content with doing every unit test manually, because this was only a training exercise and I didn't have my Shell unit testing framework at hand.

Summary

You don't need to add the complexity of "yet another platform to maintain" to your development unless there are pressing reasons. Try looking into this question: "Who needs what - and what is the minimum we need?" Talk with the team, discover the real need and find the simplest way to reach your purpose.

Only add extra tools when you have sufficient evidence to prove that a few lines of code can't meet the same purpose. Remember: Every tool adds complexity and work.

Permit changes to the Sprint in Scrum?

Sparked by a recent article on LinkedIn, I would like to say a few words about changes to the Sprint. Some people consider the Sprint plan sacrosanct, others want to define a rule set for changes - yet others are very open-minded about changes within the Sprint. What is a good idea, what isn't?

Is the Sprint Plan fixed?

Many teams assume that a Sprint is immutable, and the Scrum Guide advises fixing the Sprint content as well.
This provides safety and a certain level of comfort for the team. Developers know well ahead what to do. The team can reliably forecast how well they will achieve their plan with a high degree of confidence. That's the plus side.

There are a number problems with this, such as:

1. Plans must be made upfront with a high degree of detail - possibly at a time when the best solution is not yet known.
2. Unnecessary features ( = waste) may be delivered if they made it into the Sprint backlog - resulting in additional rework in the future
3. Opportunities that become known during development are not monetized immediately - reducing the possible value delivery of the team

All these points are violations of the Agile Manifesto, so you should be careful with statements that "Scrum supports this". Yes, it does - but only to a certain extent, less your Scrum becomes un-agile.

There are good reasons to keep the Sprint scope fixed regardless, for instance to protect the team against whimsical stakeholders who consider "everything urgent" and who come up with "even more urgent" things on a daily basis.
Keep in mind, however, that this is a different problem from the problem which work developers do and when they fix their plan.

When is changing Sprint content a good idea?

Instead of proposing a huge rule set, there is a simple guideline: "When it makes more sense to change the plan than to pursue it" (ref. Agile Manifesto value #4: "Responding to change over following a plan")

Here are some of the main reasons when it makes sense to change - you may find others:

1. The team decides it is so.
2. The product is dysfunctional until the change is implemented.
3. A stakeholder has a very urgent need and is willing to pay the price.
4. Not making the change would damage the credibility and reputation of the team

How do we change the Sprint?

The Scrum Guide suggests "Sprint termination". A Sprint termination means: "We stop everything we're doing, end with a Retro and restart with a new planning". That may indeed be an option if the change proposal makes the entire remaining Sprint unfeasible. It may not be necessary if the upcoming change is of a lesser nature.

Here is what needs to be done, at a minimum:

1. Estimate the change: How much of the Sprint's remaining capacity will be redirected?
2. Re-Plan Sprint Backlog: Pull enough items out of the Sprint to fit in the change, then add the changed item.
3. Plan the change: The change needs to be subjected to the same kind of item planning as any other item that is already within the Sprint. This may require an extraordinary planning meeting.
4. Inform stakeholders: Some items won't be touched by the team because of the change. They may either return to the Product Backlog or be discarded entirely.

What happens after we changed the Sprint Backlog?

We shouldn't be doing that on a daily basis. It should remain a special event. At the end of the Sprint, the team reflects in a Retrospective why this change occurred.

Here are a few questions the team might want to ask:

1. Why do we see changes to the Sprint Backlog as a problem?
2. Why are we getting these kinds of late-and-urgent changes?
3. Did we do our best to clarify the impact of the change?
4. Did we do our best to minimize the effort and scope of the change?
5. How could we have discovered this information earlier?
6. How can we increase their agility to deal with this type of change easier in the future?

The Retrospective should result in conclusive actions for improvement.

Summary

Changes to the Sprint shouldn't be the end of the world. In a domain with high uncertainty and rapidly changing outward circumstances, change should be a normal thing. When it makes sense to change, you can not hide behind Scrum rules to justify actions that don't make sense.

Apply common sense.

Hierarchy or Anarchy? - A false dichotomy!

"We need a hierarchy, otherwise there would be anarchy!" - have you heard this claim, or similar claims? How can an organization function without a hierarchy? We have been taught from an early childhood to believe that the absence of hierarchy leads to anarchy, which - in turn, is utter chaos and it's impossible to achieve anything. Is that true? Having experienced a different model, I claim: No. The absence of hierarchy is not necessarily anarchy. Let me explain ...

Hierarchy - the need for prescription

A classic example of a hierarchy

What is hierarchy? Based on the original meaning of the word, it means "sacred order" - or, an order that must be maintained at all costs. A hierarchy is implicitly optimized to remain a hierarchy. This is about status, but also about achievement.

In a hierarchy, the highest person defines the goals for the entire organization. With their direct subordinates, they extract subgoals for those people - and so on. Everyone contributes to the common goal by following the prescibed personal goal and making those below them achieve their goals. The hierarchy would fail to achieve it's overall goal if anyone would deviate from their prescribed goal.

The main purpose of leaders in a hierarchy is to ensure goal alignment and goal achievement within their sphere of control.

Without this kind of prescription, the hierarchy would achieve nothing.

Anarchy - the absence of structure

Let's look at the alternative to hierarchy: anarchy.

Anarchy: The nightmare of every manager

What is anarchy? Based on the original meaning, it means "no order" - or, the absence of order. Anarchy is a highly unstable condition and implies local optimization. Achievement in an anarchy depends only on the individual.

In anarchy, everyone has their own goals and pursues them as they see fit. The outcome of an anarchy depends on the outcome of the individual. There may be common goals or common directions, but they don't mean anything. Failure to achieve personal goals doesn't affect others, so the (not existing) organization in anarchy is unaffected by individual failure or changes to individual goals.

In an anarchy, there is no leadership and no control. Goals are not aligned, achieving a goal depends on the individual alone.



Is that what we have to choose between? If it were so, human society could indeed not function without hierarchy.
But wait ... this is the false dichotomy. There is an alternative:

Holarchy - Integral parts of the Whole

In a holarchy, there is no "up and down" and no permanent structure.

Holarchy is a different model. The term means "The part and the whole are the order" - or: the order is implicit rather than explicit.

What is holarchy? It's quite difficult to understand if you haven't seen it in action. At first glance, the self-similar (fractal) structure may be considered a hierarchy, but it isn't. In a holarchy, there is nobody giving orders. There is also nobody listening to orders, and yet, people pursue a common goal. Nobody prescribes that goal, they take the goal and align around it.
A holarchy is much more effective than a hierarchy, because nobody wastes time defining goals for others and checking their accomplishment - everyone is fully focused on achieving the one, common goal.
People are not "managed" to achieve a pre-defined objective that partially contributes to an organizational goal, much rather they find others around them with whom they are better at achieving their common goal: people with whom they can share labour to achieve something better, something more, something higher than they could alone.

As activities and focus change and steps are accomplished, people's collaboration circles (holons) change dynamically. Every holon is transient and people may be part of more than one holon. Holons themselves may be part of holons. It all depends on what makes sense.

In a holarchy, leadership is different - it's as transient as the holons themselves. Holons aren't "managed", yet there are people forming holons and keeping them together, helping them move forward and joining them with one another. These people are leaders. They have no title and you may not even recognize them.

Summary

Holarchies avoid the problems of anarchy and solve the problems that are endemic to a hierarchy, making them a viable alternative to both. They have other problems, but that's a different story to be told at another time.

The "5 Co's of Teamwork" maturity model

What makes a team effective - why is teamwork more desirable than a bunch of individuals working on the same topic? This maturity model sheds some light into why we should care about a proper team atmosphere in the workplace.

Competition Level

At the first level, there is rivalry within the team. Team members have the same or similar goals, yet different ways of reaching them, and these are not considered equal. There is an idea that there is a "best way" of doing things and that only one solution is "best".

Interaction
 Interactions are driven by competition, i.e. by finding ways to be better than other team members.

Focus
Team members are focused on being better than one another. They pay attention to what others do in a negative way, either to find something they can take advantage of - or a flaw they can use to put down others.

Problem solving
When one team member has trouble, this is taken as an opportunity to increase one's own standing rather than help the team produce better results.

Effectivenss
The effectiveness of the team could be written as 1+1 <1, because the effectiveness of the team is limited by the most capable team member - and even then, that person diverts a significant portion of attention towards securing their rank rather than a beneficial outcome.
In the worst case scenario of competition we see sabotage, i.e. purposefully conducting actions that reduce the effectiveness of another team member for personal benefit.

Scaling
Additional team members will exacerbate this condition, i.e. effectiveness drops as additional people enter.

Conflict Level

At the second level, team members have common - or at least overlapping - goals.

Interaction
Interactions are driven by conflict, i.e. when one team member feels that another is interfering with their way of accomplishing their goal. 

Focus

Team members focus on their invividual goals, which may or may not be comaptible with those of other team members. They don't pay much attention to what others do, unless it gets into their way. 

Problem solving

When one team member has trouble, that's that person's problem and will typically be ignored by other team members unless it also causes trouble for others, in which case people often tend to consider the person as the problem.

Even when goals align, a different understanding of the same goal may lead to incompatible approaches, creating friction.

Effectiveness

The effectiveness of the team could be written as 1+1 = 1, because the effectiveness of the team depends on how compatible individual goals are with one another. When goals are diametrically opposed, the team will spend their energy in a tug-of-war, where only the strongest person's goal will be realized. 

Scaling

When a new person enters a conflicting team, their effectiveness will depend on how compatible their goals are with those of others.

Coexistence Level

The third level - a local optimum - is when team members choose a way of working that will not create conflict.

Interaction
Interactions are limited to a minimum, as team members feel that interaction might reduce their own effectiveness.


Focus
Team members focus on individuals goals, which have been purposefully chosen in a fashion that is independent of others. They can choose to ignore other team members, because their work has been created to be independent.

Problem solving
Problems faced by a single person are limited to that person, the team is not the place to receive much help. Other team members feel unaffected by such a condition.
Peaceful coexistence requires a high level of respect for one another, lest the team falls back into conflict.

Effectiveness
A coexisting team operates on a "1+1 <2" effectiveness, depending on how often team members work individually to achieve the same goal, i.e. duplicating work. In the very unlikely case that all goals are also organizational goals and do not produce an overlap, coexisting team members will be as effective as the sum of each individual. The major downside of coexistence is a slowed problem resolution.

Scaling
Joining a coexisting team will drive the team members back into conflict until the new team member has found their place.

Coordination Level

At the fourth level, the team members coordinate their personal goals and approach, finding ways to increase overlap in their goals and work for mutual benefit.

Interaction
Interactions are limited to goal synchronization - reducing conflict and increasing the alignment of both goals and approach throughout the achievement cycle (identify, realize, achieve).

Focus
Team members first and foremost focus on their individuals goals, yet they chose those goals in order to achieve a uniting, greater goal. Coordination implies prioritizing one's individual goals in comparison to other goals within the team, so team members need to subject their individual goals towards those of others at times.

Problem solving
Coordination requires frequent synchronization, problems get addressed at those synchronization points.
The level of synchronization points as well as the quality of discussion occurring at those points reflects the effectiveness of addressing problems. The resolution of problems then depends on the way the team chooses to address identified issues.

Effectiveness
A coordinating team achieves "1+1 =2" effectiveness, minimizing the waste of duplication and speeding up problem solving. The downside of coordination is the time required to coordinate, which is usually more than compensated through enhanced alignment and problem solving.

Scaling
Coordinating teams tend to deal with newcomers well, since they identify problems in teamwork fast and address them effectively.

Collaboration Level

At the fifth level, team members collaborate to reach shared goals. They choose an adequate approach towards reaching their goal which allows every team member to utilize their strengths. Collaboration is a prerequisite for hyperproductivity.

Interaction
Interaction is a continuous condition rather than happening at discrete points, yet driven by need. Team members will "pair up" where it makes sense and work individually when there is no benefit in working together. Synchronization points lose their meaning as team members are constantly synchronized.

Focus
Everyone understands and contributes towards the team's most important goals. Each team member's activity focuses on reaching shared objectives. Collaboration requires aligning personal goals with team goals and reducing the amount of goals that are pursued simultaneously.

Problem solving
Team members use each other to overcome problems, and problem solving - like interaction - becomes a continuous state. The resolution of team problems is prioritized over individual accomplishment. Problems are readily transparent, as the need for resolution will increase interaction.

Effectiveness
Collaborating teams will be effective at "1+1 > 2", as team members are no longer limited by their own ability. Taking advantage of synergies and bringing together strengths allows the team to achieve goals which are greater than the individuals could.

Scaling
Harnessing everyone's strengths, collaboration enables teams to perform even better as new team members join. To maximize effectiveness, new team members should complement, rather than duplicate, the strengths which exist within the team.

Closing remarks

The five levels are not "clear-cut" transitions. At different times, the team may jump between those levels and individual members within the team may operate at different levels as well. This model serves as a guide for observing and classifying where the team stands and draw conclusions for potential corrective actions.

Reflection Points

• At which level do you feel most comfortable? Why?
• What are the key impediments preventing your team from reaching the next level?
• Which structural elements of the organization affect your level of teamwork?
• Which beliefs, behaviours and actions result in your team's current level?
• What can you do to help your team reach a higher level?
• How do you avoid getting stuck at one level?