Business Model Canvas: Step by Step

The Business Model Canvas (BMC) is a strategic tool for the product owner that helps to build a faster and more visual representation of new products and services. It consists of a panel divided into nine blocks, such as those displayed in the picture below, which represent the basic elements (building blocks) that compound a business model.

The main goal of this panel is to generate value proposition that meets and potentiates the desired objectives before actually implementing the product or service. Below, I depict the dynamics of how to build a BMC, created by Alexander Osterwalder.

Building the Canvas

In order to apply the Canvas as shown in the picture above, you can either use a printed version (using this pdf) in A0 size to facilitate the collaboration, draw on a whiteboard (simple layout to replicate) or create it online (Lucidchart has a helpful template).

Lucidchart is a good option for distributed teams because it can be built online in a collaborative way. There is also a web-app available created by the makers of BMC.

The Canvas already filled in below can be split into two dimensions: the dimension located on the right contains more subjective and “emotional” elements, while the dimension on the left contains structural and logical elements. It is recommended that you fill out the Canvas from right to left. This way, the wishes and aspirations of the stakeholders can be addressed before you start defining in a more factual method.

Dimensions and Basic Elements

The illustration below shows how the nine elements of the Canvas are integrated with each other. As mentioned before, we will begin to explore the right dimension of the Canvas first.

We start by putting the block “Customer Segments” in place, which maps who we are targeting to provide value and who are the potential customers to our desired objectives. For instance: customers over the age of 50, women, customers from California and so on.

In the block “Value Proposition,” ideas are generated to fulfill the needs of the potential customers, while always keeping in mind the business objectives that are driving this product or service. Examples of value propositions include cost reduction, agility, convenience, customization and decision support. The Customer Segments and Value Propositions blocks are the main elements that will lead the remaining components of the Canvas.    

Once we determine the potential customers and value propositions, it’s necessary to think about how we can link these two fundamental components. This is the purpose of the “Channels” or “Distribution Channels” block, which includes items such as the delivery, blog, newsletter, customer service and webinar. These are the channels that distribute and deliver the value propositions to the customers.

Next, we should understand  the “Customer Relationships” block. In other words, we should figure out how to strengthen customer involvement with the business. To give a few examples: business development partnership, customer retention, customer support, online chat and feedback.

The last right block is the “Revenue Stream,” which translates to the path to generate revenue based on the recommended value proposition. Examples include a monthly subscription, direct sale, paid ads and license.

The image below depicts the fundamental elements of the right dimension from the Canvas.

In the left dimension of the Canvas, we can find more direct and objective definitions that sustain the components mapped in the right dimension.

The “Key Resources” refer to the resources directly associated with the business model operation, such as teams, machines, investments and technology platforms.

The “Key Activities” are all activities needed to meet the value proposition, build channels and keep relationships. We might consider managing the social networks (a powerful mechanism to strengthen the customer relationship) or building a web store.

“Key Partners” are people who contribute to both key activities and key resources. Some partners (outsourcing companies, for example) can provide machines to drive towards any key resource. Other types of partnerships can supply contractors or execute some of the key activities, such as monitoring the social networks.

Representing the required costs to maintain and build the proposed solution is performed by the  “Costs Structure” block, which indicates, for example, the amount of money necessary to pay the machines’ maintenance, contractors, OPEX, infrastructure and resources.

The picture below illustrates the basic elements of the left dimension from the Canvas.


The Business Model Canvas is useful for driving the conception of new products and services through its nine basic elements from both rational and emotional perspectives. It also allows the teams to brainstorm insights, ideas and opinions around the product, enabling a common understanding among the stakeholders as well as generating strong performance indicators towards a strategic innovation.

It’s another helpful tool for the product owner to conceive a new product, service, website, e-commerce or game.

Have you used the BMC before? Do you plan on using it in the future? Let me know in the comments section below.


Forming, Storming, Norming and Performing in a Scrum Team

An essential Scrum Master role is to facilitate the formation of new teams, and this is where Tuckman’s “Stages of Group Development” model can help.

In 1965, Bruce Tuckman published “Development Sequence in Small Groups” which detailed four phases of group development. By understanding the evolution of team behaviour, the Scrum Master can specifically target each phase:

Forming: The assembled team discusses the development vision, roadmap and high-level features. Initially, they work independently on tasks and act as a group of people rather than a team. Lacking clear alignment and trust, the team members avoid conflict and instead focus on collecting information and agile planning.

The Scrum Master works in the forming stage to promote positive initial team behaviours. Leadership style at this stage tends to be directive and teaching. Activities include:

Running a kick-off workshop to orient everyone involved in development Creating the right physical environment to aid collaboration Engaging with businesses, customers and stakeholders Encouraging the team to confront threatening topics

Storming: Team members begin to form opinions of each other and start to challenge situations they feel are unfair or wrong. Personality clashes and arguments highlight tensions in relationships and disagreements over practicalities. Decisions are difficult due to the high level of uncertainty that is present.

Note that approximately half of teams skip this phase; for the rest, the Scrum Master strives to get the team to face its conflicts and find solutions. The leadership style transitions to providing guidance by coaching and mentoring. During the storming stage, the Scrum Master:

Facilitates workshops to understand conflicts and identify solutions Empathises tolerance and demonstrates the value of differences and diversity Promotes agile values and principles

Norming: When agreement and consensus have been reached, the team starts to become cooperative and cohesive. Roles are understood and ground rules are established. The team members take responsibility and work together for mutual success. By becoming accountable, they begin to understand each other’s contributions.

The empowered team assumes authority during the norming phase, which alters the leadership style to emphasize facilitation and support for the team. The Scrum Master’s actions include:

Facilitating customer workshops Organising external activities to increase socialisation Developing communities of practice and mentoring Ensuring the team does not grow complacent and avoiding potential conflicts Focusing on constant innovation and incremental improvement Helping the wider organisation to support the team and transform more widely

Performing: With firmly established roles in place, the team can focus on achieving their common goal, often with a high level of success. A strategically aware, motivated and skilled team working in an autonomous and self-organising way can move dynamically and address issues quickly.

During the performing stage, the leadership style is participative and collaborative, with the fully empowered team providing its own solutions. Scrum Masters:

Encourage a high degree of autonomy Support growth within the team, both personal and aligned with delivery goals Facilitate development review and disengagement activities

In 1977, Bruce Tuckman and Mary Ann Jenson published “Stages of Small-Group Development Revisited" which added a fifth stage, the adjourning stage, which covers the break-up of the team. This phase recognises the sensitivity and insecurity that team members face following successful completion of development. In this stage, the Scrum Master facilitates a review to enable self-reflection and recognition of contributions, followed by the co-creation of a plan for transitioning roles.

It is important to consider that changing circumstances, such as the addition of new team members or unexpected market conditions, can cause teams to revert to earlier stages in the model. Even high-performing and long-standing teams can run through the same cycles, with experience providing the knowledge and tools they need to move through the stages faster.

Tuckman’s model also highlights why a move to long-term teams and product development make sense due to the lengthy period of time required to form high-performing teams.

Mathematician George Box once said, “Essentially, all models are wrong, but some are useful.” The value of a model is in its application, and Tuckman provides us with a simplified view of the development of maturity within a team and its relationships, ability and required leadership style for each phase. By using this model, the Scrum Master can empower the team with the right tools to move forward.

Consider your current team using Tuckman’s model – which phase are you in? Let me know in the comments section below.

What Kids Taught Me About Being Agile

While agile initiatives now spread beyond IT within the corporate world, one may wonder why we tend to brand these changes as “transformations” or “transitions.” After all, we are merely going back to a state of being which we have in fact experienced for years, not as adults but as children. 

For several years, I ran my own small education business. I taught children from the ages of 6 to 10 about science and technology, specifically space and robotics, my favorite topics, with the help of LEGO® bricks, my favorite toy.

As I was busy with this endeavor alongside my daily job as a software development manager, I got plenty of opportunities to compare first-hand the difference between kids being agile and adults doing agile. This was a topic that surfaced in many agile coaches’ narratives, but it was only then that I truly understood it.

Make a Plan, Then Change It

One of the most striking things I noticed during my students’ activities is that when children are taking on a task, whether self-initiated or not, they always seem to have a plan. The plan is clear only to them and continually changes, but it eventually leads somewhere. Even if that means starting again, they reach the finish line quickly and iterate successfully.

It’s no wonder the Marshmallow Challenge, your typical team building exercise in a corporate offsite event, is often said to be better accomplished by children than MBA grads.

Ask Why (And Truly Mean It)

When children ask “why?” they are truly curious and will likely dig further and further until there are no more answers to be had. They have neither a fear of asking nor a sense of shame, a quality which increases their learning and creative capabilities.

By contrast, adults tend to think twice before asking questions, and we feed ourselves on guesses instead.  We tend to be paralyzed by our culture, our pride or fear of judgment from our peers. Either way, we miss opportunities to enrich ourselves, while children have already moved on to their next learning experience.

Flag It as It Is

Learning how to give feedback to each other can be a daunting task for agile team members, and we often associate criticism with its destructive meaning. In contrast, I would safely bet we have all experienced a very direct, sometimes crushing and often tactless (but always honest and “fairly” constructive) feedback from a child. We can all learn something from them.

Collaborate Rather Than Cooperate 

I often tried to divide work and responsibilities among children in my workshops so that they could cooperate in building a larger LEGO® assembly. In most cases, my efforts initially failed, or at least felt like a failure. In fact, these little builders were often inclined to drop their own task to go and help a playmate realize his or hers.

By trying and iterating on the task together while sharing a goal, true collaboration was born and the children’s learning experience was greatly enhanced. The opposite tends to be true in a professional environment, where a culture of individual goals and target-setting has traditionally reigned supreme.

While agile coaches can certainly help guide and scale your organization in the right direction, asking yourself what has happened with your inner child (minus the therapy…), or simply observing your own children, should help you open your mind to the changes to come.

Have you observed any other ways in which children excel at agile principles? Let me know in the comments section below.

Happy 20th Birthday to “Managing the Design Factory”

“Managing the Design Factory” by Donald G. Reinertsen was first published 20 years ago, and its tools, techniques and message are still relevant today.

In software delivery, Scrum and agile are not mandatory. I find it useful to remember this, since I often find myself in conversations with people who are interested in the successes and risk mitigations that Scrum enables. As a Scrum Master, understanding when and how Scrum can be successful helps me make responsible and informed recommendations. Yes, it’s true, I don’t always recommend Scrum, but I do always recommend that people learn more about it, try it and then decide for themselves.

So, I’d like to recommend a book to you, which was itself recommended to me by Mike Cohn when I attended his product owner training in London last year. If you have not read it, then I hope the following brief review will encourage you to do so.

First published in 1997, in the early days of Scrum and before the Manifesto for Agile Software Development was created, “Managing the Design Factory” takes a ground up, economic value-driven view of software development. It will be of interest to senior IT and business managers, product owners, Scrum Masters and anyone else with an interest in the history of software.

It contains no explicit references to agile or Scrum, but it does contain clear expositions of process design that can be seen in the Scrum Guide. I have found the beautifully concise Scrum Guide to be enriched by the detailed and soundly reasoned explanations in “Managing the Design Factory.”

Each chapter is clearly and methodically written, and simple but effective planning and estimation tools are provided. This allows the reader to systematically acquire the knowledge and techniques that will enable them to make the best decisions possible when designing the process best suited to their own particular business requirement for software.

Some of the key messages I have taken, and which we hold in our minds when we enact Scrum, are:

The purpose of the design process is to make money. In addition, we need to understand where in the process value is being added or taken away. This is manifested in Scrum’s product backlog, where there is constant review of value and priorities. Manufacturing process design and software development process design require different approaches. In fact, applying manufacturing quality standards to software not only removes the potential value of the software, it reduces software quality. It is worth remembering that there are still national and global enterprises whose software delivery processes are based on manufacturing process rules. In the software delivery process, where there is risk, there is also potential value. Development of small increments of software product release business value more quickly. As I am sure we all know, the delivery of regular, valuable software is a core agile principle.

“Managing the Design Factory” addresses manufacturing process design, firmware process design and software process design. This breadth provides excellent context for the reader to understand what is different about the design of the processes as well as the management of the people involved in software development. This knowledge will help managers decide if Scrum and agile could work for them.

For those of us who are already convinced of the benefits and value of Scrum, this book may help you understand why Scrum works and thus may also help you explain it to others – something I find myself doing almost daily.

Reading this book has made me a more informed, more confident and more effective Scrum Master. So, thank you, “Managing the Design Factory,” and Happy 20th Birthday!

Have you read “Managing the Design Factory,” or any of Donald G. Reinertsen’s other books? What did you think? Let me know in the comments section below.

Don’t Skip Your Recommended Daily Dose of Scrum

Can you remember what you ate a few days ago? How about a week or a month ago? We only tend to remember the extraordinarily delicious (or extraordinarily un-delicious) meals.

But all of them were important, even if we don’t remember them. How do we know that? Because if we hadn’t eaten any of them, we would not be alive right now. Similarly, missing a meal every now and then won’t do you terrible harm, but if you do it frequently enough, you will start to lose weight and become weaker.

In this way, daily scrums are like food: they play a vital role in keeping your team’s development process healthy. But, for some people, the daily scrum is an acquired taste. Sometimes it can feel burdensome, unnecessary or un-delicious, and you would rather skip it altogether. Resist the temptation.

Here are some objections you might hear from developers, product owners or even management regarding the daily Scrum. Perhaps you have even felt this way yourself.

“It’s boring. The code they are working on has nothing to do with me.”

The daily Scrum is a way to keep everyone informed about what everyone else is working on. This is important for cultivating a cross-functional team. Team members also learn how the code they are working on fits in with other code that someone else is working on, which is especially important if not everyone in the team is working on the same project.

And, even if they are working on entirely different applications, the types of issues different team members face can have common traits. If Alice hears that Bob, a junior team member, is wrestling with a memory leak that she knows how to fix, she can take that opportunity to coach Bob.

“Developers already talk to one another throughout the day. We don’t need a daily meeting for that.”

The spontaneous conversations that take place during the day tend to be operational in nature: Alice has a compiler error; Bob needs some information from Carol before he can define an interface; Dave can’t figure out why a file is missing and so on. They are focused on fixing immediate problems, whereas the daily Scrum is more of a tactical planning meeting.

It is not a problem-solving meeting, but rather a problem-surfacing meeting. You find out who is blocked and who can help, or who can find out who can help.

“This is a status meeting.”

Yes, developers share their status. But that’s like complaining that you must inhale in order to breathe. If the daily scrum consists solely of answering the three questions of what did I do/what will I do/what is holding me back and nothing else, then it is indeed just a status meeting.

But, just like you can’t breathe by only inhaling and never exhaling, your daily Scrum will not be effective if all of the communication is pointing away from the developer and there is none in return. As mentioned above, the daily Scrum is a problem-surfacing meeting, and problems can go unnoticed if no one comments or asks any follow-up questions. The Scrum Master might need to take the lead in digging a little deeper while the rest of the team develops the confidence or interest to do so themselves.

“It is ineffective or rude if you don’t let anyone except developers participate.”

Would you need people from outside the team to participate in a technical coding discussion? Would they even want to? The daily Scrum is a higher-level meeting than that, but only by a hair. If people can see it that way, they might be less inclined to insist on participating. And, with a 15-minute timebox, there isn’t much time for other people to participate effectively anyway.

Having daily Scrums is like maintaining a healthy eating regimen. You might not always want to do it, and some of the meals might be bland or occasionally downright yucky, but you can’t skip them. You might not see an immediate negative impact from doing so, and people might even be happy about it (yum, junk food!).

However, it can erode your team’s agility and cohesiveness over time. Similarly, positive effects may take time to manifest, but they will help your team bond and achieve an elevated level of performance.

Have you heard any other objections to the daily Scrum, from team members or otherwise? I'd love to read your experiences in the comments below.

Scrum Does Not Need Heroes

We all know one: the person who rushed in to save the day or rescue the project. We know the people who work late into the night to finish the presentation or fix a problem with the website. Or, perhaps we have been the “heroes” ourselves. I myself was one for a while. At least, until I understood.

It’s easy enough to see how the opportunity arises for a hero to rush in and save the day. Judging from the expectations some of my clients have had, Scrum is (supposedly) about filling up a sprint with stories and then having the team literally sprint to the finish. For various reasons, when this does not work out and the project is in peril, they cry out for a hero to save the day. Who will answer the call?

A Culture of Hero Worship

In fiction, the hero has a lot to live up to. It is as if fiction writers with a conventional concept of a hero know that their heroes ultimately cannot keep up with the idealistic image that people project on them. They do not grow beyond their own sacrifice, leading to many stories ending with the heroic act itself or the death of the hero.

Think of Frodo from the book series “Lord of the Rings” by J. R. R. Tolkien. After his long and heroic journey to destroy evil once and for all, he does not return happily to his life. Instead, the story ends, with a vague reference of him sailing away to an unnamed country to spend the rest of his life there.

While this can make for intriguing cinema, should we not be allowed to question this cultural concept of a hero when it comes to real life?

In reality, the real work only begins after the “heroic act” has been performed. We must ask ourselves, “How did things go so wrong in the first place? How can we prevent a similar disaster in the future?”

Standing in the Way

Put yourself into the shoes of the lead developer. You are the one who knows the ins and outs of the entire system. If you are working on the issue, it gets done twice as quickly. You are that good.

You fear how the team would perform if you were not available or on vacation, so you tell them you are always available and that they should call you whenever there is a problem, no matter the time. Essentially, you think they are not ready for the world.

But, after a while, it slowly dawns you that your team cannot meet the challenges because you never actually let them try to do so. You are the reason they are standing still.

Men have to have heroes, but no man can ever be as big as the need, and so a legend grows around a grain of truth, like a pearl.

-Peter S. Beagle, “The Last Unicorn”

As a manager, you need to understand why it is crucial not to cry out for a hero. The heroic act does not change the person doing it, and the accolade of those around him or her will eventually end. After the situation has been resolved, the hero usually returns back to ordinary work---disenchanted, since he or she cannot keep working at the same pace on his or her own outside the team.

What these heroes are left with is either pride--which can turn on its head by causing them to become more defensive, less transparent and less of a part of the team--or a sense of abandonment, if they feel their contribution is no longer valued when it’s not urgent.

If you praise heroes by their sacrifice in the face of emergencies, you no longer differentiate tasks by their value, but by their praiseworthiness and visibility. Important but less visible half-finished tasks will be dragged along through several sprints until they cause a fire---with the hero again coming to the rescue, and the vicious cycle repeating itself.

Aim for 100% Completion, Not 100% Exhaustion Rather than demanding heroism and sacrifice by adding more stories to a sprint than the team has pulled from the backlog (or would have, if you had let them!), I recommend setting a goal of sustainability. This helps the team to become more confident in their abilities by removing the need for the “hero” of the team. It might even make the “hero” more productive by having her abilities focused not on putting out fires, but on his or her own strengths. Instead of looking at the hero as a self-sacrificial super-human, I recommend learning to get comfortable with the real hero as someone who can break conventions and who speaks openly instead of purposefully running the project into the ground just to prove a point.

There is no need, in a productive team, for one person to carry the weight of the world on his or her shoulders. We do not have to feel responsible for everything that is happening, only to then complain that we cannot manage it on our own. If the actual result is more important to us than social recognition, we have a simpler option to improve the world without having to sacrifice ourselves: We can focus on our strengths and help others in the team to reach their full potential.

Are Scrum Masters the True Heroes?

Even if you do not have a hero in your team, management might think you do, or that you should. Some clients even see Scrum Masters as a type of “team motivator” whose main task is to whoop the team into shape and reach new levels of productivity. If you do have a “hero” on your team, you might be better off either moving the person into a technical support role outside the Scrum team, or developing that person into a Scrum Master.

But, keep in mind that even the Scrum Master does not fit the image of a traditional hero. His or her main task is to oppose false heroes or paradigms within the company. Sure, the responsibilities of a Scrum Master also include identifying, analyzing and removing impediments, but that does not mean that the Scrum Master takes over tasks the rest of the team could just as easily work on themselves.


The traditional image of heroism does not fit into the Scrum team. A Scrum Master needs to be aware both of a culture of hero worship within a company and individual team members who are engaging in self-sacrificial behavior at the cost of long-term sustainability. 

The real heroes are the ones who break conventions and stand up against false heroes. They will be the ones who contribute to the success of your project and your team.

How do your team members share work among themselves? Do you have specialists, like a “super-programmer”? Have you seen evidence of hero worship in your company’s culture? Please let me know in the comments section below.  

Culture Wars: The Battle for Hearts and Minds

Recently, VersionOne released their 11th annual State of Agile report detailing the current state of agile across multiple organizations spanning the globe. 

In the report, VersionOne listed the top challenges respondents reported having experienced in adopting and scaling agile. Their number one response (with 63 percent of respondents citing it as an issue) was that company philosophy or culture was at odds with core agile values.

This issue jumped out to me as getting to the heart of the problem that many who adopt agile experience: the great culture war, or the battle for the hearts and minds of your organization. When adopting agile, we must recognize that extensive knowledge of the framework is not enough and that changing the culture of a company is the more necessary and arduous task.

Why are so many seeing this as a challenge to their agile adoptions? What is it about company philosophies or cultures that conflict with core agile values? More importantly, what could we do better as an agile community to address this issue and provide solutions to this widespread concern? 

Agile values are best represented by the four main statements put forward in the Agile Manifesto. These statements are not buried deep within the training material and should be well known by any company looking to implement an agile transformation.

In fact, I would imagine that if there is one thing executives or other sponsors for an agile transformation certainly know about agile before they pull the trigger on an adoption, it is the Agile Manifesto. Why, then, do we find our companies at odds with the most fundamental concepts associated with agile?

What I have heard multiple times from various organizations is that there exists a very real disconnect within their companies between some layer of the management structure and the teams who are implementing agile.

In other words, parts of the organization are implementing agile while other parts continue to use waterfall methodologies. The team level will practice iterative, incremental development while reporting up to layers of management that still operate on what David Hawks calls “a requirements delivery model rather than a requirements discovery one.” 

What this creates is a mushy translation layer within organizations where some poor souls are asked to translate agile concepts into traditional waterfall-speak. That group is given the impossible task of translating iterations and story points into a Gantt chart with hard deadlines for delivery. They are asked to take overly complicated requirements documents and translate them into user stories. 

These are insurmountable challenges which will only produce frustration in both those trying to translate and those expecting the translation. There is no Rosetta Stone to accomplish this translation because the concepts simply don’t translate. Any translation that a company might settle on must compromise on one side or the other, and it is usually the agile side that takes the hit.

If an organization wants to change its culture and realize the full benefits of an agile transformation, a more holistic approach is needed. Both management and team layers need to understand not only the “how” but the “why” behind each change that is being made.  

Two suggestions for organizations that are seeking a more holistic approach:

Consider arranging training not only for your teams but also for your directors, vice president and C-level leaders as well. Within the past few years, The Scrum Alliance has created the Certified Agile Leader (CAL) certification course that many of those in management and leadership positions would be wise to consider investing in. This course will help organizational leaders understand what to expect and learn how they can encourage and fan the flames of their organization’s agile transformation. Consider “seeding” your transformation by contracting outside coaching to help teach not just one-time concepts but overall culture on a day-to-day basis.

Now, you might be thinking to yourself, “Of course you would say that! You’re an agile coach and consultant!” And you’d be partially correct. One of the main reasons I decided to do what I do is because I wanted to focus on an area where I felt I could make the greatest impact. However, there are many great coaches and consultants out there and most of them would tell you the same things. 

Culture isn’t something you can transfer in a one- or two-day course. Culture takes time and is learned through osmosis and by example. When a team member suggests that a sprint be extended so that the team can finish all the work, a coach is needed to explain not only that Scrum is timeboxed by rule but also that we do this to establish a definitive point that we can review the work to see what adjustments we need to make to move forward.

This leads a team to think of the steps of the process as more of what they were intended to be – a framework. When that shift occurs, a team begins absorbing the cultural concept rather than simply parroting back answers from a book. That leap, in both organizational leaders and in teams, is what will transform the culture of an organization and it is the best way to combat any disconnect between a company’s culture and core agile values. 

Hearts and minds will always be more difficult to change than procedures and processes. However, in order to change the culture of an organization, that is exactly the target we should be attempting to hit. Our job as agile leaders is to draw this clear distinction and point our teams in the right direction. Only then can we begin to address the number one issue organizations face in their path towards a successful agile transformation.

What do you think is the hardest part about transitioning to agile? Are there any culture clashes you’ve observed in your own organization? Let me know in the comments section below.


Myths and Misconceptions About Trust

When I was a teenager, I was bitten by a German Shephard out of the blue, or so it seemed to me at the time. I never trusted that dog again, mostly because we never met again. I'm sure that if we had, we might have become friends and I would have become much better at reading him. The incident certainly hasn't stopped me from loving dogs.

The romantic in me would like to say that this incident is what sparked my interest in trust. It didn't, but it's a nice story, and it illustrates a couple myths and misconceptions about trust.

Myth: Trust Is All or Nothing

For a long time, I believed that if I trusted someone not to bash my head in, it meant that I completely trusted them. You either trust someone or you don't, right?

Not exactly.

I like to drive convertibles at high speeds up and down mountain roads. Roads like the one in the above picture. When that picture was taken, I was not at the wheel. Does that take trust? You bet. Would I trust the driver with anything? No way.

Would you trust the driver of a getaway car with your wallet? Can you trust a very competent rally driver to look out for you in difficult personal circumstances? Can you trust a co-worker that would drive you up or down this mountain safely not to go behind your back to reap the fruits of your labor?

Trusting someone for one thing does not necessarily mean that you trust them for everything. It's quite possible to trust a co-worker not to gossip about you, yet have no trust for them at all about the way they handle their own or your mistakes.

Myth: Trust Is a Matter of Life and Death

It certainly can be, and in many professions it is, whether between teammates or between the person performing a service and the person undergoing it. However, most of us don't work in the fire department or have medical jobs. Most us have office jobs, where life and death situations are few and far between.

In those circumstances, trust revolves more around emotional safety. Can you make a promise because you can trust someone to deliver so you won't have to face another's wrath? Can you trust someone not to judge you? Can you trust someone to walk their talk?

Myth: Trust Is About Competence

According to some, competence inspires trust. While I don't disagree, I don't entirely agree, either. Competence, or being good at something, is more about inspiring confidence. Specifically, confidence that someone is the right person to get a job done. On the other hand, trust is more about being able to rely on them using that ability to do the job right and get the best result possible.

Take the co-pilot of Germanwings flight 9525, trained to the T and perfectly competent to fly an aircraft to its destination. His ability also made him perfectly competent to fly it into the ground. Which, unfortunately, is exactly what he did on 24 March 2015. Despite his competence, he should not have been trusted to fly on that fateful day.

This next example hits a bit closer to home for me. The people I wouldn't want behind the wheel on that mountain road fall into two categories. One group simply lacks the ability to safely get me to the top and down again. I have zero confidence in their competence.

Another group consists of the people that can complete the trip safely, but I am uncertain if they will. Not because they may have a death-wish like the German co-pilot, but maybe because they tend to drink a little too much in the evenings, or because they are easily distracted and tend not to be focused on the job at hand.

Myth: Trust Arrives on Foot and Leaves on Horseback

Google “trust quotes” and this comes up a lot. It's a widespread belief.

However, trust isn't slow to arrive. Yes, some people will not trust anyone unless and until they have "proven" their trustworthiness. Most people, however, function the other way around. They will trust until they are proven wrong.

Further, being proven wrong once isn't enough to warrant a complete lack of trust. Yes, it will make you more cautious, but your trust for them doesn't simply fly out the window. People are quite capable of distinguishing between intention and effect, and are generally willing to give someone the benefit of the doubt.

Even when proven wrong a couple of times, that doesn't mean that all trust is gone, because trust is not all or nothing. Oh sure, after banging your head against the wall several times, you will not trust X to deliver on time anymore, but you can still rely on X to deliver high-quality work. And what if X were to deliver quality goods on time several times in a row?

Regardless of the initial level of trust for others that you operate from, that level of trust is in constant flux. Brené Brown uses a marble jar analogy to illustrate this.

Your marble jar for Peter starts with an initial number of marbles in it. Every action by Peter either adds a marble or takes one away. For example, Peter remembering your mother's name, inquiring about your recent exam, delivering quality work on time or being discrete about something you told him in confidence will add marbles. On the other hand, delivering something late or of inferior quality, being harsh to you or someone else or always saying yes but doing no will remove marbles from his jar.

So, where does the popular belief that trust leaves on horseback come from?

I have no idea. My guess is that we are often unaware of the effects of other people's words and actions on our level of trust for them, perhaps because questioning your trust for someone feels like a betrayal in itself. When you've finally had enough of someone's failures to act trustworthy, it feels like emptying the jar in one fell swoop, when in reality it has been running on fumes for some time already.

Myth: Trust Happens Automagically

Everything I've read about agile and high-performance teams stresses the importance of trust. Trust between team members, trust between teams and trust between teams and their stakeholders. And yet, none of the agile frameworks or methodologies I’ve seen go any further than that. We are all apparently expected to "get" it and get on with it. "Trust is important. Now go forth and trust each other."

Coaches and facilitators do get a bit more training and can find a lot more resources on trust building exercises. Unfortunately, most trust building exercises I have had the pleasure of reading or being subjected to are not about building trust. They are about building a connection. Connectedness is a lubricant that makes trust easier: you are far more likely to trust someone with whom you have broken bread, played or exchanged personal information. But a connection is not trust itself.

What everybody also seems to forget is that trust or team building exercises and activities can just as easily destroy trust when the person you previously thought was pretty nice turns out to be an utterly unreliable partner in the exercise.

What's more, just like training a dog doesn't just happen during obedience classes, trust doesn't just grow or erode during exercises and events intended to build it. Trust levels wax and wane with every observed word and action. If you want trust levels to improve, you will have to work at it all the time. This doesn't mean you can't slip up, just that when you do, you have to acknowledge it and make amends.

Myth: Trust Must Be Earned

This myth is one of my pet peeves. I am firmly in the "trust until proven wrong" camp, even though it may sometimes be with a lot of trepidation.

That doesn't mean I trust everyone for anything in every situation. For example, I am very much in favor of assessments and tests during the hiring process. I could say that is because of cognitive biases that make people believe they are better than they actually are. While that plays a part, the true reason is that hiring is a process with a lot of conflicting interests, and assessments may add some much-needed objectivity.

But, don't put people through a wringer just to gauge their trustworthiness as a human being. Doing so is a clear signal of distrust that is clearly heard by the person on the receiving end. Distrust begets distrust. They may tolerate it if it's the way to gain a prize they want, but, if anything, it will lower their trust (and respect) for their "testers."

Hearing an agile coach utter this myth really got me on my high horse.

Besides, it is futile. If you are not willing to trust me, there is nothing I can do or that I can give you that will make you trust me. Because, as we’re about to discuss, trust can't be built.

Myth: Trust Can Be Built

Now there's a bummer. Bet you didn't expect that one, especially with all the trust building exercises, ice breakers, team building activities and what have you that all intend to build trust levels in teams.

Unfortunately, it is true. There is nothing I or anyone else can do to make you trust us.

It's not like I can stack packets of trust on you and that will increase your trust for me. All anyone can do is speak and act in ways that will facilitate your trust for them to grow. However, whether it has the desired effect or not depends entirely on whether you allow it and are willing to trust.

Trust can't be built or earned, it is given and it grows.

So, are all those exercises, ice breakers and games in vain?

Absolutely not.

They are essential for trust to have a chance. They create conditions and get people to interact in ways that are conducive for trust to grow. You need to take people out of their "normal" work -- the transactions of day to day business -- and put them in situations where they can interact as people.

Interacting as human beings, with as little interference from formal hierarchies as possible, is what makes people more comfortable with each other and what will allow them to interact more easily and with less trepidation in their "transactional" work. It allows trust to grow and to be given.

Myth: Trust Is Optional for the Bottom Line

Just like "leaving your emotions at the door" is wishful thinking, hoping that you can make do without trust is daydreaming at best. Sure, companies where distrust reigns supreme can be successful and make a profit. I just wonder how much more profitable they could be if they worked on increasing trust and happiness levels. Read Patrick Lencioni's "The Five Dysfunctions of a Team" to see where an organization can leak money left, right and center when trust issues run rampant.

And, if you want the people in your company to innovate, to be creative and to be open to change, then you need them to be willing to make themselves vulnerable to the words and actions of their co-workers. That takes trust. Loads and loads of trust.

So, What Is Trust?

Trust is multi-faceted.

Trust is feeling emotionally safe.

Trust is knowing that someone will use their abilities appropriately.

Trust is resilient.

Trust is a two-way street.

Trust is essential for smooth collaboration so innovation, creativity and change can flourish.

Trust is in constant flux, it waxes and wanes with every interaction.

Trust is a verb. It needs to be worked on and you need to be aware of the effect of words and actions on trust levels.

Trust is not built or earned. It grows and is given.

If you have any additional thoughts on trust that I haven’t addressed here, please share them in the comments section below.