I frequently work with teams of people from a range of companies, industries, and backgrounds, and its during these sessions that I think back to those larger thoughts about how we experience our lives as individuals and as members of teams.  What makes some teams click, thrive, and deliver?  How do some groups of people truly share a common goal and work creatively to achieve it?  Why do some groups of people seem to only suffer through projects and then deliver dismal results, consistently?  What is the definable difference between the experiences of these different groups?  Why are some people happy with their job, their company, their project, their healthcare, their family, their car, their house, their spouse, their life, while others would seemingly choose to be dissatisfied no matter what they may be blessed with?  Where are the connection of neurons responsible for our ability to be happy and productive on a team?  And does this ability to choose happiness relate to better relationships and results at work?  How do I grant the gift of effortless success and indomitable growth to teams that struggle endlessly to achieve even modestly positive results?

To help me answer these questions, I turned to an insightful book The Wisdom of Teams: Creating the High-Performance Organization. In the book authors Katzenback and Smith define a team as “a small number of people with complementary skills who are committed to a common purpose, performance goals, and a common approach for which they hold themselves mutually accountable.”  Although I agree wholeheartedly with their definition, the book did not satisfy the curiosity I had about what components make certain teams tick and others tock.  I needed an understanding at a deeper level, I needed to examine the DNA of teams.  So instead of reading more about teams from a business perspective, I instead looked into those double helixes that seem to determine everything about us, our very own DNA, to see if any insight could be found.

The human genome project promised to finally unlock the secret recipe for what makes us who we are.  And like so many other great scientific promises of the past, it failed to yield an answer to everything, but rather provided a perfect foundation for even greater questions.  Although our DNA provides the building blocks for our physical being, it cannot alone explain the curiosities of individuals, from our personalities, to our attitudes, to our propensity for success, or our ability to trudge inexorably to failure.  This mysterious exclusion is expressed effectively in the observation of identical twins, where the DNA encoding remains identical, but where nearly all else is unique, especially when the brain is examined.

Like our DNA, we often cannot choose the members that make up our team, but equally similar to DNA, it is not simply the members of our team that pre-determine our possibilities.  Too often I hear individuals complain that consistent success would be possible if only they were assigned to the right team or if the right team were assigned to them.  This superficial failure of perspective can often become a self-fullfilling prophecy, yielding the expected negative results as a consequence of subconscious actions driven in support of the consciously expected outcome.  As with many mysteries of life, perspective and belief are more powerful than we allow ourselves to consider.  We seem to be more content to apply unreasoned reasons to our perceived consequences rather than seeking to drive meaning from those things for which we could have affected the outcome.

Recent discoveries in the world of science confirm the notion that we are more than our parts, both on the individual and team levels.  These scientific revelations point to a beautiful aspect of life that affirms that we are not limited by our structure, but are allowed infinite possibilities through the wonder of chaos; an inability and impossibility of perfectly predicting results based solely on observing conditions, thus free will is born and an infinite number of possible minds follows.  Author Jonah Lehrer states “that [this] is the triumph of DNA; it makes us without determining us.  The invention of neural plasticity, which is encoded by the genome, lets each of us transcend our genome.  We emerge, character-like, from the vague alphabet of our text.”  And as is true for individuals, it is equally true for how effectives teams can be, regardless of their own DNA, regardless of the individual components of the team.

Supporting these ideas, in a 2002 Science paper entitled “Stochastic Gene Expression in a Single Cell” Michael Elowitz of Caltech demonstrated that biological “noise” (a scientific synonym for chaos) is inherent in gene expression.  His results further solidified the unfolding scientific belief that it was this “noise” that held most of the possibilities for emergence in design for organisms, which contradicted the earlier collective belief that natural selection alone held this potential.  These discoveries, by extension, illuminated the idea that without this inclusion of chaos, then every cell that was created by the same DNA would operate, behave, and produce the same results, but we know that this is not the case.  In fact, without this beautiful inclusion to our evolution, we would not experience the diversity of life that we do.

Digging more deeply into what constitutes success in these complex adaptive systems (organized as teams), yields the result that diversity in experience, knowledge, personality, and drive is what allow them to truly excel.  The equivalent in nature was captured by Darwin when he wrote that ”the more diversified the descendants from any one species become in structure, constitution, and habits, by so much will they be better enabled to seize on many and widely diversified places in the polity of nature.”  A team’s diversity is one its greatest strengths, so long as the diversity is expressed and exercised regularly.

Teams are not doomed to failure as an inevitable consequence of the composition of it’s members.  Similarly, individuals are not merely limited to the sum of their specific DNA coded sequences.  And if these statements are true, how do we then affect better outcomes from both teams and individuals?  Just as individuals are formed by their experiences that shape their neurons, bringing temporary neural order to chaos, so too can teams also allow their experience to help bring consistency in results to their previously unpredictable outcomes.  But in order to make this happen, teams need two very important components in place: 1. An ability to clearly define their current state set against their preferred results (this allows the team to define the state of dissonance between reality and possibility, thus developing creative tension in the structure).  2. A mechanism that allows the team to utilize experience to shape future team decisions.

I am a firm believer that:

- Given the opportunity, most people would rather succeed than fail.
- People are very well aware of organizational constraints that limit their ability to achieve and succeed.
- Most people feel limited in their ability to affect change in their job.

So what is the answer?  How do we elicit better results from our teams?

If you are still with me this far, then it is only fair that I provide you an answer, right?  Unfortunately, as much as I would like to, I cannot provide an answer, only a direction.

The potential source for your organization’s power lies in the unexplored richness of experience and understanding held by your people.  You may believe that your organization actively solicits input and feedback, but if your organization is like most, you don’t, at least not well enough.  You will know when you have breached the barrier that separates average teams and corporate culture from their extraordinary equivalents.  You will know because you will discover the roar that exists on the other side of silence.  Do not dig unprepared for what you may find, the roar is often deafening.

Seeing this huge gap between team types begs the obvious question, what is the difference between the teams?  Is it company size? No. Is it the industry?  Nope, seen great teams in every industry including DoD, government, tech, and finance. Is it the goodies provided for free in the kitchen?  Maybe, but I don’t think so.

So what is the secret sauce of these hyper-productive teams?

As you might guess, it is not any one thing, but a combination of many different factors that all support the single-headed direction to support the creation and continued operation of a highly productive team.  So what are the ingredients?  Here is my unscientific, and definitely un-exhaustive list:

1. Great people.
   We cannot pretend that only process matters.  Spend any amount of time digging into great teams and you are likely to find a fair number of great people, people that would be great on any team.  Get enough of them together and you have a good shot at a great team.
2. Organizational culture supportive of making mistakes in pursuit of greater return results.
   Teams that are comfortable at making mistakes often find that they also produce extraordinary results.  True success is often comprised of multiple failed efforts that did not sink the team, but rather allowed the team to learn things they could not have learned otherwise.  Working within a corporate culture that recognizes this is a key component to super teams.
3. True team based delivery culture (which means this is also taken into account during things like individual’s annual reviews.)
   Teams that recognize that we are not simply individuals working in close proximity, but a team where we must all be engaged with one another’s work.  I tell teams looking to achieve amazing results that each member of the team must care as much about their neighbor’s work as they do their own.
4. Team members that share a sense of purpose, vision, and passion for their work.
   If team members believe that they are contributing to something greater than their individual part, then they will care at a much greater level than their individual contribution.  Work to ensure that a team can share this vision and goals begin to shape themselves.  Better yet, teams begin to manage their own incremental improvement, otherwise know as the team holy grail.
5. A company that cares as much (if not more) about their employees as they do about their customers.
   At the base of it all, we must feel appreciated at our place of work, or we may not be able to cobble together the above components.  Companies that treat their employees as commodities will likely only experience amazing, hyper-productive teams sporadically, rather than as a expected result of a team-based product development environment.

[Let me state clearly, this list could likely be much, much longer, so please feel free to add to it in the comments. Whole books can, and have, been written on the subject.]

A the Heisenberg Uncertainty Principle states “any system development activity inevitably changes the environment  out of which the need for the system arose” so true is it that any team activity will likely change the culture out of which it was born.  Corporate culture, although seemingly unchangeable when our teams operate seemingly at its mercy, is always in flux, as this cultural effect evolved not from proclaimed edict, but the work done by teams and the resulting response from the company in which they operate.  Changing this culture to enable and encourage hyper-productive teams is a joint effort from the great team that seeks to produce extraordinary results and the company that chooses to support the behavior that these teams exhibit.  Although it sounds like an easy choice for companies to make, you would be surprised just how often I encounter organizations that seem to want to thwart these great teams.

Have you had the pleasure of working on a team that was hyper-productive?  One that truly exemplified the notion that the whole is greater than the sum of its individual parts?  What was the secret that you found to be the linchpin to success?  Did you notice that happy teams produce better results?  Did you notice that teams that have fun together are able to more easily maneuver around obstacles that might otherwise sink an average team?  I hope so, because it is these experiences that will continue to push me to better define what those magical, secret ingredients are for those teams that define what it truly means to get work done.  And as my friend Rod Behbood says, “Do Work Son.”

Happy Easter everyone!

The approach to writing the Constitution was not orderly, nor was representation of responsibility divided among states based on their size or population.  It was based on one single fact: those who showed up were allowed/requested to assist in penning the effort.  Those who showed up were able to vote on inclusions and omissions.  Those who showed up ultimately made a greater impact than any other opportunity in history.

During that stifling hot summer of 1787 when the Continental Congress held their special session in Philadelphia, the very small state of Delaware showed up.  They didn’t send 1 delegate or 2, they sent 5.  That might not sound like much, but the average number of delegates on the floor of the Continental Congress that summer numbered at just 30.  The delegates from Delaware showed up.  Day after day these delegates showed up.  After the session concluded for the day they continued the conversation and work outside of the Congress walls.  Delaware.  In contrast, New York attempted to send delegates but never had enough together at one time to achieve a quorum and were subsequently left out of every single vote.  Delaware’s impact on the final version of our Constitution was “stratospheric”. [The Little Big Things. Tom Peters. 2010]

For the next two days I will be delivering a class on the topic of Agile Project Management.  And being in the city where our Constitution was penned, I will be including this notion that showing up can often amount to half the battle.  I rarely write to the least common denominator (read my other posts if you doubt), in fact I write about those qualities and traits required for consistent excellence, but in this case let me clear…Excellence is not possible if we fail to show up in the first place.  Our ability to influence change and produce excellence in our personal and professional lives requires that we show up.  Consistently.  As the adage goes, we may not be able to perfectly predict when opportunity will avail itself to us, but showing up on a consistent basis greatly increases the likelihood that we will be present when that bells rings.

Delaware showed up.  Not because they were told that the Constitution would hold more importance than any other single document in the history of the country, they showed up because it was their duty and they were seeking any possible opportunity.  Why didn’t other states show up?  Why didn’t other states organize and participate at the intense level of Delaware?  Well it was a stifling hot summer, remember?  There was no air conditioning of course, and the thought of spending long days arguing fine details of a document that may not amount of much just did not rise to the level of importance for several of the states to make the journey.  I’m talking about you New York.

Be a Delaware.  Rather than trying to time your efforts, simply apply your excellent efforts on a consistent basis and you will be blessed when reviewing your work with the benefit of hindsight.  Show up and be ready.  Without this first step nothing else much matters.  As my dad used to tell me, all the potential in the world doesn’t amount to much.

Well, my in-flight internet is about to be turned off.  Until next time, think about the simple things that make all the difference.

Bill Gaiennie

To all of the residents of this particular community, it was like any other spring day, tending to their gardens just outside the fortress walls, readying their fields to provide the food that would supply the needs of everyone for the year.  But this was no ordinary day.

It started as a low rumbling, and as each minute passed, the rumbling got louder, signifying to the town’s residents that there was something unknown approaching, and approaching fast.  In those times, precaution was the measure of the day, so all of the residents outside the city walls quickly moved behind the protective barriers, ensuring that they would be able to weather the force of whatever was on its way.  After everyone was safely within the garrison, they closed the fortress gates, manned lookout positions on the upper walls, and armed themselves in preparation for the unknown.

It wasn’t more than a few minutes after they were fully readied that they spied the first wave of attackers on the far ridge, and it wasn’t but a few minutes longer that hundreds of attackers were now fully positioned along the walls, readying their attack.  And attack they did.  The initial attack was followed by an even more brutal, elongated barrage of arrows, battering rams, and intimidation.  But the town held their own, holding off the attack, and keeping the community safe.  But the barbarians at the gate were not to be driven off.

One day of this siege turned into two, and then two into three, until the town found itself fighting for survival for a number of weeks.  The townspeople knew they would not be able to survive forever, they only hoped to last longer than their attackers.  But food supplies were running low, and the men responsible for thwarting the attack were getting weak.  They had no access to additional supplies, and were cut off from the outside world.  They did, however, have an abundant supply of sacred cows within the township’s walls.  Unfortunately, not only was the idea of killing a sacred cow taboo, it was also a horrible crime.

But these were not ordinary times.  Should the soldiers defending the attack fail, the town’s sacred cows would almost certainly be slaughtered by the barbarians.  But, if the town’s soldiers were to kill some of the cows to provide food, they would likely be stronger and better able to continue the fight and perhaps prevail.  There really was no other alternative, the soldiers knew that in order to have any chance at saving the town, the people, and their way of life, they would have to re-evaluate the sacred nature of their cows, even if just a month ago this thought would have been abhorrent.

So in a bold attempt to save their community, these brave men evolved and re-defined the place of the cow in their society, ultimately to the townspeople’s benefit, and to the cow’s obvious demise.  But the town survived.

So what does a town and it’s sacred cows have to do with Agile teams?

Plenty.

Sacred cows roam free in many of today’s companies, never being questioned, never being examined objectively, simply they are revered by those that are forced to live with them.  Sacred cows can take many forms, but are easy to spot with the simple question “why are we doing this?”  If the answer that returns is “because we have always done this” or “this is the way it is done here,” you likely have yourself a sacred cow.  And as most companies that have moved to an Agile approach know, sacred cows most often times need to be slaughtered.

Choosing to slaughter sacred cows is a much different exercise when the decision is made while there are barbarians at the gate.  This type of decision springs from necessity, or more often, desperation, and ultimately results in something far short of a true changing of culture, a step that is required for most companies looking to move from waterfall to Agile.  Choosing to slaughter a sacred cow when there are no barbarians at the gate results in a decision made in an effort to improve rather than a decision in an effort to simply survive.

Now, don’t get me wrong, in the grand scheme of things, it is still a better situation to be able to dispatch with sacred cows, regardless of the impetus.  At times, being forced to remove sacred cows can result in a greater comfort level in identifying additional cows that should be asked to leave.  It is a muscle that needs to be stretched from time to time so that it does not atrophy.  But as many of you are likely aware, most larger companies simply do not encourage, let alone allow, the examination of these stale relics of the past, but instead have misplaced pride in the history of policies and actions that brought their company to their current position.

Learn to evolve, or plan on starving to death.

In today’s business climate, with its rapidly changing competitive landscape, those companies that choose to not examine their own sacred cows will likely find themselves in the unenviable position of needing to make these decisions while barbarians are banging at the gate.  The recording industry is a great example of a large organization that was unwilling to examine their own cow.

The compact disc.  A golden example of how sacred cows detrimentally influenced the recording industry.

The compact disc was a boon to the recording industry.  It was cheap to produce, had superior sound quality, and were selling phenomenally well, in spite of a price point that was often complained about by their customers.  The recording industry was able to enjoy this situation for more than two decades.  They enjoyed this hugely beneficial climate for so long that is effectively created a sacred cow, one that would only be challenged after they were forced to, but ultimately much too long after the point in time they could have slaughtered the sacred cow for their advantage, rather than simply survival.  A college student named Shawn Fanning created a simple piece of software that allowed users to trade copies of their music across the internet.  Napster created a shockwave across the industry, but it was only the first in a long time of technologies that would allow customers to find their music quickly and at reduced cost.  There was a window of opportunity for the recording industry to see the changing tides, but instead they had tunnel vision, only seeing the glory days of the CD, and the money that went along with it, and chose to fight reality in their effort to bring the past to the present.

And they failed miserably.  And they continue to fail even today to some extent.

Steve Jobs was the first to successfully challenge the sacred CD cow with the advent of iTunes, and after a short period of time was able to prove that it does not make sense to leave your sacred cow sacred.  Often times it is important to wield the cleaver and put down the cow that has an organization following beliefs of the past during times which require an evolution in approach.  Sacred cows are rarely sacred forever.

But in light of all of this, it is not easy to bring our own sacred cows to light.  They are often sacred for a reason (although rarely a really good reason mind you), and those individuals that do choose to point the finger at the cow in the room will likely be met with scorn or dismissal by those other individual’s intent on protecting the institutions of the past.  Clearing these cows from our hallways and boardrooms takes courage.  And in reality, there is safety in numbers in these types of endeavors.

Become a Sacred Cow Hunter.

It often takes nothing more than keeping a vigilant eye.  Encouraging (or requiring at first) some type of ‘inspect and adapt’ mechanism within your organization, where a safe environment is created and allows for anyone to call out a sacred cow sighting.  Companies must believe that if any value, belief, process, policy, or corporate mantra is valuable enough to be kept, it should also be strong enough to be challenged.  It is cancerous in any company to allow a festering sentiment about ‘why something is done’ to grow without address the why behind the what of the policy.  Transparency in communication from the top down and the bottom up is most often sufficient to flush out cows hiding in the dark corners of your organization.  And if you think your company has none, they are much better at hiding than you are at finding, so keep looking.

This highly skilled team of aviators recognized that they could not possibly fly as far or as long without teamwork. But this spirit of teamwork did not end with the decision to maintain an efficient formation. They recognized that in order for each of the pilots to be safe, they would need to take care of each other, even when disaster struck, which it did one brisk autumn morning…

The morning had been uneventful, each of the team’s pilots maintaining a tight formation, and a vigilant eye on the ground, because on this particular morning, they were traversing enemy territory. And even though this was a dangerous mission, this mission was much like most of their other missions, as they often were forced to travel over possibly hostile terrain. But unlike most other mornings, a trailing member of the formation was struck, by what no one could be sure, but struck nonetheless, and within moments, his ability to continue flying was affected severely: he was going down. He didn’t have a choice to eject, but rather piloted his disabled craft safely to the ground so that he could assess the damage. But as experience would show, being on the ground where he was much less maneuverable, he was at a greater risk of attack. In order to keep a member of their team safe during emergencies such as these, two fellow pilots also descended from formation, landing near the downed team member, and provided protection while repairs were made. These guardians would stay by the side of the disabled pilot until he was ready to fly again. To this fleet of pilots, teamwork meant never leaving a fellow pilot behind. After a short while, the downed pilot was able to successfully repair his vessel and all three took back to the air, rejoining their squadron. Alone, the pilot may not have survived the ordeal.

This is a true story, although it is a story that likely first took place thousands of years ago. And it is a story that continues to play out even today. You see, the pilots in the story above were not the pilots you may have been thinking of, these pilots were geese. Geese offer an incredible example of teamwork and how teamwork enables each member of the team to achieve more, travel greater distances, and weather more intense emergencies than they would survive alone. Geese use this tool of teamwork because although it requires a commitment to something greater than each individual, it repays that commitment with many more benefits not available without this pledge of membership.

So what do geese flying in formation have to do with Agile teams?

Plenty.

I would venture to guess that no company in existence would openly say that they do not believe in teamwork.  I would further venture to say that most of these companies would state firmly that their teams are very good at demonstrating team work in the projects they undertake.  But the truth of the matter is that most teams rarely demonstrate the type of team work that produces results proving the possibility that the whole truly can be greater than the sum of the individual parts.  The word ‘teamwork’ has unfortunately been reduced to nothing more than a term on the balance sheet of requirements for a group of project associated individuals; a definition never verified, never authentically encouraged by the organization, but believed to exist nonetheless.  It is a word that has lost its power.  It is routinely applied to describe a group where the group behavior does not merit its application of meaning.  It is overused, under-realized, and misunderstood because of each of these are true.  And yet only a small percentage of ‘teams’ out there truly endeavor to seek the rewards that come from achieving a level of performance and professional satisfaction that is the byproduct of individuals that sacrifice their distinction, their difference, and their dissimilarities in their pursuit of that which is greater than any one person.  They pursue the quotient that is achieved when individuals become teams.  When individual output transforms into teamwork.

Agile requires teamwork in the truest sense of the word.  Agile processes reward and recognize good team behavior in the spirit that good teams can produce great results, and as teams mature, great teams can produce extraordinary outcomes.   Don’t believe me?  Then let me pose a question to you…

Have you ever been a part of a team where everything seemed to click?  Where if you had an issue, someone on your team was there to help almost before you were able to ask?  Have you ever been on a team where the work seemed less like work and more like an expression of your and your team’s passion and energy?  If so, then you are not alone, as most people have actually had the experience of achieving this level of team maturity that results in true teamwork.  If you were not able to relate, then it is up to you to create this atmosphere with your own team, on your own project.

But before we can truly become a team, we have to also address the flip side of the coin, and that is the dysfunctions that can easily sink the most well intentioned ship of individuals who set out to discover the holy land of team performance.  Patrick Lencioni did a very good job of identifying these major areas in his book, The Five Dysfunctions of  a Team, so instead of reinventing the wheel (or the team), let’s use Lencioni’s model as our foundation.

Dysfunction One:  The absence of trust among the team members.

I think that I can safely say that if you do not have trust, you do not have anything…at least you do not have anything so far as it relates to creating a true team.  What do you have when your team members don’t trust each other or don’t trust you?  You have a group of individuals working in close proximity, but you do not have a team.  You also have a group that is not able to focus their efforts on creating a truly great product, because they must divide their attention on ensuring that they are not going to be stabbed in the back.  Even if the distrust does not rise to the levels where your resources begin to connive against one another, you still have a group that cannot truly communicate, because true, effective, healthy communication is based on a foundation of trust.

Dysfunction Two: The fear of conflict.

Great teams fight.  Perhaps the word ‘fight’ is a bit strong, but great teams are not afraid of conflict, because out of conflict can emerge true resolution.  I say true resolution, because resolution can happen without conflict, but it is not authentic because it typically is simply a result of one party giving in to avoid the conflict, rather than remaining passionate about the best outcome.  Conflict is not beneficial simply for conflict’s sake, but when teams fear confrontation and conflict, communication suffers, knowledge sharing suffers, and ultimately the individuals begin to manage their own actions from a place of fear, which never returns great results.

Dysfunction Three: The lack of commitment.

We use the word commitment a lot in Agile, but in this context, the word commitment is more aligned with being absolutely committed to the team’s goal rather than our own individual objectives.  When a team of individuals is committed to achieving the goals of the team, no other possibility exists, and when faced with adversity or the risk of missing an objective, the committed teams gets creative to resolve their own issues.  Commitment does not have a back door through which we can escape when times get tough.  When a team embraces their commitments, there is little that they cannot not accomplish.

Dysfunction Four: The avoidance of accountability.

The buck stops here.  Not at the desk of the project manager, but at the door of the team’s war room.  The team’s ability to remain accountable to their commitments means that creativity is likely to flow in the face of project difficulty.  I am not accidentally being vague here, I am purposely avoiding being too specific because I have seen many varied examples of how a team’s creativity in their attempts to resolve issues has surprised even them.  Keep all possibilities open, along with your mind, and allow the intelligent people you have assembled for your team to be accountable, even up until the very end.  With accountability comes the possibility of glory, don’t take this away from your team.

Dysfunction Five: The inattention to results.

In order for any team to have the possibility of making improvements, they must be able to honestly assess the effectiveness of their results.  It may be nice to sugar coat our reality, so that we don’t hurt anyone’s feelings, but all we are doing when we practice this soft-handed approach, is sweep under the rug the very information that is most likely to assist us in improving our future efforts.  Results are not good or bad, it is just information.  What teams do with this information will determine the character of the team.  Team’s that choose to ignore the difficult to digest results will continue to produce that same quality of results, but instead of improving their actions, they will simply develop an immunity to the effects the poor results use to inflict.  If it is painful for a team to honestly and authentically examine their results, then this is a sure sign that they need to examine them in detail.  Allow the team to feel the pain, experience any negative reaction that comes from this examination, and most importantly, use the total experience to open up the possibility of valuable conversations that will allow the team to avoid repeating it all again in the future.

There is no ‘I’ in Agile.

Individuals are great, I love having superstars on my team, but when we work together to achieve a common goal, I only recognize good team behavior, not individual efforts.  The people on your team are just like people everywhere, they are going to behave in ways which reflect how they are rewarded and recognized.  So if your company does not officially reward team’s that perform, only individuals (like during annual reviews), start the conversation to address this.  In you don’t, please do not be surprised when all of your cheerleading over the important of teamwork, team play, and team building are met with cheers, but then never realized.

Agile requires many different areas that reflect the need for a true cultural paradigm shift within most companies, teamwork and team building being one of the majors, so get ready, it is now up to you.  Becase if you have made it this far in my post, you have heard the bell.  And you cannot un-ring the bell, you know.

Cook and his crew arrived in Taihiti on April 11, 1769, but soon realized that this was not the undiscovered territory they sought, so they departed the island chain and headed southwest.  After a brief stay on the islands of New Zealand, Cook again set sail in search of the great southern continent.  Finally, on April 9th, 1770, a full two years after then left their home country, the crew of the Endeavor finally arrived at the continent we now refer to as Australia.  Having already experienced the native populations on several other islands, Cook was well prepared for any possible contingency, from friendly natives offering gifts (such as his experience with the Sandwich Islands off of Alaska) to those natives intent on attacking his men (as he experienced when encountering Maori native tribes on New Zealand.)  But this experience, this arrival to a new land, was different.

When Cook’s ships anchored off-shore of this new land, it drew no reaction from the natives they could see working close to the shore.  Cook knew that they must be able to see them, but still there was no reaction, no staring by the natives out to the sea with wonder, no anxious reactions; simply nothing.  Studying more closely the accounts of James Cook and his botanist Joseph Banks, it is revealed that the natives must have been able to see them, as the ship sailed only a quarter mile off of their shores.   Other villagers must have been able to see the ships, but they too ignored these foreigners.  Cook wrote in his journal that “an old woman followed by three children came out of the woods…she turned her gaze toward our ships, but offered neither surprise nor concern.”  Then the Aborigines began to prepare dinner “to all appearance, totally unmoved by the sight of us, though we were less than a mile from their spot.”

Cook and his crew was not only perplexed by this curious behavior, but were now determined to make contact with these natives.  Cook writes “we set out from the ship intending to land at the place we saw these people…as soon as we approached in our small boats, from the rocks two men scrambled down to the shore, each armed with a lance, with an intent to attack us.”  For some unknown reason, these natives were unaffected and unaware of the large ship anchored just off the shore, but were hyper-aware of the smaller boats that were landing upon their shores.

After that initial contact with the native people of Australia, it was discovered that this population was simply not able to see these large ships, as they represented something completely unknown to them.  As Cook explained, his ship represented “the largest artifact ever seen, or unseen as it were, on the east coast of Australia, an object so huge, so complex, and unfamiliar as to defy the native’s understanding.”  Cook’s ship was essentially unseen by the natives because they had no experience that such an object could exist.  Once his crew transported to the shore in smaller boats, the vision of invaders arriving by small vessels being a familiar site, the natives responded by perceiving this arrival as a threat.

Or so the story goes.  And although this story has been told many times, using different explorers and other details, all of which may or may not be factually true, the message behind the mythos is still pertinent: we tend to see what we expect to see and can easily become blind, or choose to ignore, that which exists outside of our experience.  There are plenty of terms modern day psychologists give to this type of phenomenon including cognitive dissonance, perceptual blindness, habituation, inattentional blindness, etc.

So what does the story of natives not being able to see a ship off shore have to do with Agile teams?

Plenty.

Humans (and Agile teams by extension) naturally strive to reach consonance, or agreement and harmony, among the beliefs they hold to be true.  Cognitive dissonance, or a disagreement or difference of beliefs, can occur when we try to hold two contradictory beliefs about something simultaneously.  The natives believed that ships the size of Cook’s did not exist, and thus resolved this major disagreement of what they saw with what they believed to be true, by simply ‘not seeing’ his ship when it was anchored off-shore.  Although different today, it is still a common tendency to resolve this dissonance, or difference, through any number of means, including rationalization, justification, or dismissal of one of the beliefs.  The most common method for resolving cognitive dissonance is to simply dismiss the lessor known of the two beliefs, that belief which we have less experience with, while also building positive evidence and confidence in the remaining idea or belief, which was the route the Aborigines took when presented with Cook’s competing reality.   We do this so that we don’t have to experience the anxiety that comes from weighing two completing beliefs, especially when there is disparity in the amount experience or familiarity between them.  In short, people and teams tend to continue doing what they know, even when presented with a better possibility.  This behavioral pattern reduces stress, but it becomes an impediment to true growth, as the pattern regularly precludes exploring the unknown in deference to the known.

This principle was more recently put to the test in an experiment by Jack Brehm.  Brehm took 225 female study participants, and allowed them to choose one of two items to take home as a gift.  When asked later to rate the two items, a statistically significant portion of the participants rated the item that they selected much higher than the one that they didn’t.  This might sound intuitively accurate because the participants chose that item, but even when the experiment was conducted where participants were given an item at random, the participants still rated the item they took home higher than the one they did not.  Brehm concluded that in this simple experiment, cognitive dissonance was resolved by changing opinions to match the possible dissonance of “I selected X” while also feeling that “there were some things I liked about Y.”  This phenomenon of relieving any dissonance in our beliefs was confirmed by additional research and experiments, and found it to be true for children, adults, and even capuchin monkeys.  What have our efforts for resolving this cognitive dissonance problem resulted in?

We have been conditioned to become problem solving machines, while ignoring the possibility that introducing dissonance can lead to better outcomes.

Teams that have been conditioned to become proficient at problem solving tend to find themselves as habitual ‘firefighters’ constantly seeking out the next problem to resolve, the next fire to put out.  Study after study has shown that this approach to work results in employee burn out, poor work product, and a feeling that instead of being able to design our destination, our efforts are determined by factors outside of our control.  In today’s corporate parlance, we become adept at a reactive form of decision making as opposed to being proactive, or creative, in our planned path forward.  As skilled problem solvers, we carry around a huge problem solving hammer and then understandably see every situation as a nail.  And when our hammer will not effectively ‘resolve’ the nail in front of us, we mistakenly believe that “what we need here is a bigger hammer.”  For those of you who can relate to this approach and may have been nodding your head, you know better than anyone that it becomes a self-perpetuating cycle where the bigger hammer always encounters a bigger nail, which then requires a bigger hammer, etc.  When we perceive that problems being solved will result in a greater possibility for our efforts, for our product, or for our customer, we have bought into our own belief that fighting fires is the same as preventing them.

So are you saying that solving our problems is a bad thing?

No.  Problems are identified as such because they introduce a cognitive dissonance that can assist our team.  Letting a problem exist implies a simultaneous belief that “X is bad (a problem by definition)” and “X is ok to exist.”  This dissonance cannot remain, so we either resolve the problem, or modify how we identify the “problem.”  Problems do need to be resolved, but it is only half of the equation for great agile teams.  The other half of the equation represents the positive side that cognitive dissonance can represent, but unfortunately is rarely explored by most teams today.  So let’s explore this other side…

What do you have when you are done resolving a problem?

Nothing.  By definition, when a problem is resolved, it no longer exists, so nothing has been created apart from the removal of a problem.  Again, this is half of the equation.  But can anyone argue that removing a problem is the same as creating something?  It is a subtle but fundamental difference that can make all the difference…possibly the difference between being good and being great.  Interesting to note is that often times, our attempts to resolve a problem can actually make the problem worse.  Don’t believe me?

Let’s take something we are all likely familiar with:

The problem: Ethiopia experiences famine, with a large part of its population facing starvation.

The solution: With its population starving, the obvious hammer for this nail is to provide food.  And the world rallied around this solution, providing hundreds of millions of dollars of food and famine relief.

The results: The food did help, at least for awhile.  Many people that would have starved without the aid, did not starve.  But the aid only provided time, because the underlying structure of the problem did not change, it was only addressed superficially.  But after the crisis was addressed, the plight of the Ethiopians fell off of the news cycle (as many of the Ethiopians had been helped by the massive amounts of aid), and as the news fell off, subsequently so did the donations.  Problem solved, right?  Wrong.  The mechanics of the ‘solution’ did not look more deeply into the problem to see that simply taking care of a symptom would only exacerbate the problem.  Solving the problem only relieved immediate needs, but did not seek to create a better possibility for the Ethiopian people, as they still could not provide food for themselves.  And although initially helped by the donations, the people of Ethiopia had now become more dependent on this help, and fell into greater despair, requiring again for massive aid to be provided by the concerned citizens of the world.

Robert Fritz, author of the book Path of Least Resistance, refers to this pattern occurring like this:

The Problem
LEADS TO
action to solve the problem

WHICH LEADS TO
less intensity of the problem

WHICH LEADS TO
less action to solve the problem

WHICH LEADS TO
the problem remaining or intensifying anew

Simply put, solving the problem is akin to providing a fish to a starving man, whereas teaching him how to fish is creating a new possibility for his future.  Problem-solving-persistent paradigms focus on the near term, providing a fish for tonight, but then once that man no longer has hunger pangs, this approach simply moves onto the next problem, only to have to return again in the future to provide another fish when the man is on the brink of death.  Although we may be able to keep problems from becoming catastrophes, we do nothing to truly create a better possibility.

So tie this all together.  What does this all mean and how can this help my team?

I mentioned above the possibility of actually introducing dissonance as a tool for creation.  Not sure if any of you caught this, but this simple idea is the key to truly becoming great, as a team or even as an individual (although I am not advocating for individual greatness alone for Agile teams, as I will elucidate in my next post There is no “I” in Agile.)  The introduction of dissonance exists as a possibility on the opposite end of the spectrum from solving problems.  Rather than solely relieving tension between our problems and our current situation, we can introduce ideas and opportunities that exist between our current situation and a greater possibility.  This is the holy grail for teams that strive for continuous and incremental improvement.  Identifying issues that exist is a valuable skillset, but additionally identifying the dissonance between our current situation and our potential, provides the possibility for growth, improvement, and greatness.  Simply put, we need to identify clearly articulated goals for our team and then recognize the dissonance between our current state and that which we wish to achieve.  This is positive dissonance.  This dissonance also encourages resolution, but in a positive direction, and encourages creation of something new, rather than simply a removal of problems.  Two parts of the equation, each necessary, but only addressing one of them will never lead a team to greatness.  And the identification of areas of opportunity is an acquired skill, as it can take time to truly focus on the bird in the bush as part of our overall strategy.  We must also practice not getting stuck in the rut of tunnel vision or ‘group think’ and elicit input from  every source available to our team.

If we only ask the flashlight where the dark areas of the room are, we may be missing some valuable information.

We must use our peripheral vision to see those things that we might otherwise miss, such as those that are not currently getting our full attention.  And what typically gets our full attention are the fires we are being asked to put out.  Ask a flashlight where the dark areas of the room are, and the answer you will likely get is that the room is fully lit. But of course, everywhere the flashlight points will receive light, while keeping the other areas shrouded in darkness.  Our attention is like a flashlight, and we can often miss those areas that represent opportunities or issues where our light is not focused.  And this is one beautiful aspect of Agile, as Agile acts as a very bright spotlight, showing the room as it is.  But it will only show you the things that you choose to look at, you must choose the direction in which to point your light, your focus, your attention.

In conclusion…we are either running from something or to something.  Running from a lion will keep us alive today, but will not necessarily provide shelter for tomorrow and beyond.  We must, as a team, strive to address our immediate, everyday problems for survival, but for long-term growth we must also apply our energy and attention to seeking out shelter as well.

I know this post was somewhat abstract, steeped in a some psychology, and I would guess that most of the people that started to read this post will have likely not even made to this sentence.  But for those troopers that made it this far, congratulations.  Your reward…my next post will be shorter and perhaps be a bit more fun.  Thanks for reading, I appreciate all of the amazing feedback I have received since launch this blog.  It keeps me going, so thank you again.

When an elephant is born in captivity in Africa (and I am using the word ‘captivity’ very loosely here, as there are no pens, no cages, and no fences on the majority of these properties), the owner of the newborn elephant ties the animal to a tree or post with a strong chain, thus preventing the creature from escaping.  As the elephant grows during the first few weeks, the chain that binds him is continually tested by the elephant in his attempts to free himself, but as a baby, his efforts are just no match for the chain.  As the elephant continues to grow, his attempts to break free of his confinement become less and less frequent as he learns that his might and muscle are no match for the hardiness of the restraint, so confined he stays.  Soon after, the elephant simply gives up any attempts to free himself, and thus seemingly is relegated to a life of capture, believing that his strength will never provide the effort necessary to overcome his restraints.

As an adult elephant, having been conditioned by his past experience, he can now easily be tethered to a tree with the puniest of ropes while making no attempt to break free.  He makes no attempts at freedom because he carries with him for life the belief that he does not possess the strength and power to break the ties that bind him.  This elephant could easily uproot the tree that the rope is attached to, or simply snap the puny rope, but no effort to do so is made because early in life, the elephant learned that he was not capable of doing such a thing, even though he has grown to many times the size that he was when he still had made attempts to free himself.

The rope no longer serves the purpose of physically binding the elephant, for it is not strong enough to accomplish that feat if ever tested.  No, now the rope simply serves to confine the animal’s mind, reinforcing the mistaken belief that the elephant’s current capabilities are no greater than they were when he was just a fraction of his current size and strength.  The puniest of ropes can bind the largest of elephant, simply because the elephant believes that it can.

So what does the fact that gigantic creatures like elephants can be confined by weak restraints have to do with software development teams?

Plenty.

Our belief about our ability as individuals is often seen through the lens of our past experiences.  Too often people suffer failure only to take the circumstances of that failure as a definition of the limits of their abilities.  We are just like elephants in this regard, making the mistaken assumption that our past experience equals our future potential, or lack thereof.  A team’s behavior is no different, and can often be worse, especially in a corporate climate that reinforces our limits through lack of management support in our efforts to try again that which we failed in the past.  We learn too quickly that even if we make an effort to break the rope that binds us, when we are unsuccessful we sub-consciously decide to re-write the definition of our abilities, never to test that definition again.

Now, I am not advocating enduring the classic definition of insanity, doing the same thing over and over expecting different results, although it may sound like I am.  In this old adage describing the actions of the insane, it implies that circumstances remain the same, which in life, is rarely the case.  If the adult elephant were to once again attempt to break free of the rope, it would not fall into the insane category because the circumstances surrounding the scenario of his captivity have changed.  And although these circumstances have changed in reality, they have not changed in the mind and belief of the elephant, thus the force truly confining the adult elephant is not the rope at all, but his own limited beliefs.  This is sad for the elephant, because the elephant does not have the luxury of making conscious decisions to challenge a defective set of beliefs based on outdated information.  But we do.

Often times, the best course forward for individuals or teams is not the most obvious, it is not the easiest, or it is not the most readily apparent.  But individuals and teams rarely make concerted efforts to do more than scratch the surface of possibilities directly in front of them to test whether their current actions will produce the best results possible.  Or even simply better than the results they have achieved in the past.  The lens of our past experiences through which we view our current situations often does very little to encourage innovative thinking, in fact more often than not, it values only using information from past events that lead to successful conclusions, even when innovative thinking is called for.

Take an old Sufi parable (I have changed some minor details to modernize the story a bit)…

A man was walking down the street late one night, only to come across Darren, an old friend of his, on his hands and knees under the corner streetlight, frantically searching for something.  Wanting to help his friend, the man asks what he is looking for so diligently, to which Darren replies that he has lost his house keys.  The man gets on his hands and knees to join his friend in the search.

After 30 minutes of combined effort, the man finally asks of Darren “we have searched every crevice within 30 feet of this spot, are you sure that you dropped your keys here?”

Darren replies “no, actually I dropped them about a block away.”

“What!?  If you dropped your keys a block away, then why have we been wasting our time looking here?”

“Well, the light was better over here…”

Now as crazy as that may sound, the message of the story is much less absurd.  This simple parable illustrates something far more common among software development teams, doing what we have known to work in the past without expending any effort to determine if that past approach is appropriate given new circumstances, requirements, and constraints.  The lazy approach to our efforts will often yield shades of success, but very rarely yield extraordinary results, results that exceeded our own beliefs about what was possible.  And like the elephant, what we believe to be possible is more often a factor of the limitations of our beliefs about what is possible, rather than what is truly possible.

How do Agile teams take these realities into account and use them for their own benefit?

Retrospectives.

Retrospectives are forums for communication that are held on regular intervals during the project so that the team can discuss and collaborate on their performance as a team over the past iteration.  And just like any other tool, Agile or not, your team will only get out what it puts in.  Too often, I hear about or see with my own eyes, retrospectives that prove to be a waste of everyone’s time because the team does not challenge themselves to see beyond their past experiences, to see that their ropes no longer have the power to bind them, but rather these teams get in a room, say everything went as good as it could have gone, and then leave.  These retrospectives are not the true retrospectives that assist good Agile teams in their effort to be great.  These meetings more resemble those of Cargo Cult Agile teams that go through the motions believing that they will yield the same results.

Agile teams recognize that they must truly be proactive.  And being proactive is more than just a buzzword, it is more than reacting at an earlier point in time than the last possible moment, it is a decision to create a better possibility for the sake of having a better possibility as opposed to simply fixing something that is broken.  And when something is broken, being proactive involves the team seeing how they contribute to their own problems. When individuals and teams only act when forced to by an outside element, their actions, or more appropriately, their reactions lose the power of creation, for they did not choose to create a better team, a better product component, a better customer relationship, they only chose to act in the light of circumstance.  And when that circumstance, when that reason, goes away and the fire gets put out, we all go back to doing what we did before never quite drawing the line between what we were doing before and how those actions started the fire we raced to extinguish.  We go in circles and wonder why we live this way, how we got here, and then feel hopeless in our efforts to eventually break the cycle.

Agile teams that practice mastery in the area of retrospectives never leave those meetings without identifying areas of effort that may lead to better results than they achieved in the past.  These teams recognize that it is never about the destination, it is about the continual journey that defines what we are capable of, and that definition is never static.  Unlike the elephant, great Agile teams question the beliefs about past experiences to determine if they still hold value, and when they don’t, these teams quickly rip that tree from its roots and move on to greener pastures.  The alternative is allowing ourselves to be bound by a puny rope, believing that it is not within our capabilities to roam free.  And sadly, although we have a choice to break the rope, few teams ever make the decision to do so, but rather spend their time and effort discussing just how strong this rope truly is.

So there I was at the zoo, shaving a yak, all so I could take a few pictures of my dogs at the park.

Should We Shave the Yak?

So what does shaving a yak have to do with software development?

Plenty.

Yak shaving is a phenomenon that occurs when you must complete a series of seemingly unrelated tasks in order to ultimately achieve your primary goal.  And yak shaving, as funny as the term may sound, is somewhat common for software development teams.  Yak shaving can happen when we least expect it, and is more likely to happen to those individuals or teams that lack preparation or organization.

Yak shaving is simply a waste of effort to achieve what we believe will provide enough value to outweigh the cost of the effort to achieve it.  We usually don’t set out to shave yaks, we set out to take pictures of our dogs, but then when we get sidetracked in the effort to achieve our primary goal, we forget to slow down to see whether or not the goal is worth the additional effort.  People shaving yaks find themselves chasing rabbits down the rabbit hole, searching for some elusive value, that in the grand scheme of things, they rarely find.

How Do We Avoid Finding Ourselves at the Zoo Shaving Yaks?

In Agile, we generally do not have the luxury to chase rabbits or shave yaks.  The short cycle times of iterations mean that we have to consistently keep an eye on the efficiencies of our actions.  For example, if I were required to show the pictures of my dogs (from my story above) later that same afternoon (think in terms of a demonstration of software to a client), I would have been keenly aware that my attempt to achieve that ultimate goal was not going to be served by heading to the zoo for the yak hair.  In agile we do not get the luxury of endless tinkering, or pursuing perfection, we instead need to regularly measure the goal of our pursuit against the constraints in which we must act, and more importantly, deliver.

There was a time where perfection may have been the goal, but evidence of my own experience, and history in general, bear out that the pursuit of perfection is rarely worth the effort to achieve it, even when perfection is achieved.  Agile is not about setting our sights on a sub-par goal, but rather it is about recognizing that a pursuit of perfection, when reasonably good results would suffice, is simply not worth the additional tinkering and effort to attain.  Goldplating is often the conclusion of this type of undertaking, resulting in a product that may exceed the original customer requirements, but in the customer’s eyes, was not worth the additional effort, time, and cost to achieve.  Can we in good conscience call this type of result a success?  If you have ever experienced your own version of yak shaving, then you know that the answer to that question is a simple no.

Is it ever a good idea?

If you find yourself on the way to the zoo to shave a yak, you may already be too far down the recursive road of tasks in your attempt to complete your original goal with a reasonably successful result.  But if you find yourself heading to the office to get your camera you may still be able to save yourself that trip to the zoo, so long as you are asking the question of whether wanting to take pictures of your dog is worth the effort you will spend in shaving your yak.  Having shaved my fair share of yaks, I can save you the trouble and let you know that it’s rarely worth it.

Keep it simple, clearly identify your short term goals, and keep an eye on the path you are taking towards achieving those goals.  When you get off track, when you start to tinker, when you mindlessly or endlessly attempt to pursue perfection for perfection’s sake, you may be on the way to shaving your own yak.  Lift your head, refocus, and steer clear of the zoo and you may just save yourself some time.

And if not, I have the name of a tailor that does wonderful work with yak hair.

My name is Bill Gaiennie and I am an Agile Trainer and Coach with Davisbase Consulting. If you are interested in Agile Training, please contact us.

Here I was, I had a fresh degree from a reputable university with a major in Japanese, I had big plans to get  a law degree to practice international law, but instead, I found myself in the computer software field.  So how did my plans get so derailed? 

And what does this have to do with determining whether your Agile team should use a high-tech or low-tech tool?

Plenty.

You see, nearing the end of my junior year in college, my roommate kept himself busy writing something that was very new, pretty cutting edge, he was writing websites, USING MICROSOFT NOTEPAD.  He would show me a screen full of just text, then would click a button, and VOILA, there would be a beautiful website.  I could not understand how we was turning a document in Notepad into a picture laden website.  Now although I was impressed, I was even more impressed when he told me that he was making several thousand dollars a month creating and selling these websites to car dealerships in the Los Angeles area.  For the meager budgets of college students, this was more money that I had imagined making even after I graduated.

I was hooked.  I asked (begged is probably more like it) to let me in on this business.  He told me that we would be more than happy to have me as a partner, but I would need to learn the ropes, and that meant learning how to create my own web pages.  That was it, I was now on a mission.  I went home that summer and spent most of it reading books, teaching myself all there was to know about hand-coding websites, and then creating as many as I could, each better than the one created before it.  I was honestly pretty impressed with myself, and was looking forward to joining my roommate in our business adventure together.

The summer ended and I went back to school, excited to reunite with my former roommate so that we could take the LA area by storm with our websites.  I spent an entire afternoon showcasing the websites that I had created, painstakingly by hand.  He was impressed.  He spent more time studying the actual code than the marveling at my pretty websites.

After a good deal of time, he seemed satisfied.  He gave me praise for all of the websites I created and specifically for the fact that I had done them all by hand.   He could tell that I was anxious to begin discussing how we were going to proceed with our business, but before I could ask what our next steps were, he spoke first.

He said to me “these are great, you did really well coding these sites by hand.  Now that we are ready to develop some real websites, there is this tool we can use, it’s called Dreamweaver…”

Huh?  A tool?  Then he showed me the tool, showed me just how easy it was to create websites using this tool.  I found myself getting slightly angry, after all I had spent a great deal of my summer learning how to code these sites BY HAND!  I took a few deep breathes, and then calmly asked my friend “if there was this tool that makes creating these websites so easy, then why didn’t you tell me about this BEFORE I spent all summer learning how to do this by hand?  I could have created all of these sites in a weekend, rather than it taking me all summer.”

He smiled, knowing that my reaction would likely be just as it was, and replied wisely, “you had to.  You needed to know how to create these sites by hand, how the tool would be building the site behind the scenes, so that you could get into the code and fine-tune the website so that it is just as you want it to be.  If you ONLY knew the tool, but not the basics behind it, the tool would always limit you rather than support you.”

I am not sure just how my college roommate could be so wise at such a young age, but it is a lesson I will never forget.  And he was right too.  In fact, over the following few years I thought back many times to that first summer, and was thankful I had really, truly learned the trade rather than solely relied on a tool.  This valuable, unforgettable lesson applies perfectly to a situation I see teams new to agile get themselves into.  Their situation usually starts with a question like…

Our Team Is New to Agile:  Which Software Tool Should We Use to Manage Our Project?

None.  Instead, try Sharpies, notecards, a whiteboard.  You must learn the inner workings of agile first.  You must get good at agile.  You must develop the self-discipline that is the hallmark of good and great agile teams.  If you try to find a tool to use before you develop the basic skills necessary to implement an agile approach, then the tool will always limit you rather than support you.

The tools that are currently on the market are great, some even really great.  They provide a great deal of value and they have the features and functionality to truly serve the best needs of your agile team.  Some will save you time, others will save you money, some will do both, others will do none.  But for the team fairly new to agile, none of them will likely support your team’s best efforts in getting more proficient in agile.  This post is not about pushing one software vendor over another, but about the need for your team to build their agile skills before trying to use a tool that will ultimate limit their ability to grow their own unique brand of agile approach.

When you are ready, and you really are looking for some suggestions on the best agile software packages currently on the market, come back to my blog, because I am sure that by that time I will have finally posted my list of recommendations.  Until then, spend your summer getting good at agile.  I’ll be here when you get back.

So what is a cargo cult?

The term cargo cult describes the phenomenon of natives from the islands of Melanesia in the South Pacific. During the war, the islands of Melanesia served as a staging area for the military where they built up temporary operations. The natives of the island observed everything that the allied forces were doing and, more importantly, also observed that with the allied force’s actions came cargo. The natives had little or no knowledge of the civilized world from which this cargo originated, but instead incorrectly correlated the actions of the foreigners with the pre-requisites for obtaining the cargo they so desired.  Ultimately, after the war ended and the allied troops left the island, the cargo also disappeared.  There were no more shipments of the riches that the cargo represented, so the natives did what they assumed would bring this cargo back.  The natives, these cargo cults, decided that to entice the return of the cargo they must duplicate the actions and efforts of the foreigners that were so successful in obtaining such items.  So in light of their mistaken beliefs they built dirt runways, bamboo control towers, offices and planes, sewed crude uniforms, and even crafted bamboo headsets in their effort to entice the return of the cargo.

These natives learned the foreigners ‘rituals’ very well, performing them over and again in hopes that planes would return full of cargo.  Over time they learned that even though they may be able to duplicate the ritual, it does not guarantee the same result.

How does the term apply to an agile team?

Cargo cult agile teams do much of the same thing as the natives in the story above.  These ‘agile’ teams use the correct terms, they may hold stand-up meetings, they may use story points, they may even segment their work into iterations, but fundamentally their culture does not truly change to match that of a real agile team and organization.  These teams have simply replaced their old, static project process with a new static project process, but instead have labeled their new process agile.  These teams represent the possibility of an ‘agile backlash’ that I feel is in the making (something I am currently working on for this blog.)  These teams, not completely devoted to open and honest inspection of their own processes, will likely not find agile to be the panacea of processes and will instead associate the problems they find as being caused by agile.  Any agile veteran knows that these problems are more likely to simply be problems that these teams have always had, just never knew.

How do we change from cargo cult agile, to true agile?

The hallmark of a good agile team is the ability to respond to change.  Change that can come in the form of customer initiated requests for the product as well as change in the form of guidance that comes from effective retrospectives.  Good agile teams are willing to risk, they are willing to act outside of the guarantee of a positive outcome.  They decide to risk because the possibility of great things come from endeavoring outside of the strictly known software development universe.  Organizations that are steeped in process and that have a heavy handed corporate culture face a challenging endeavor in moving to an agile approach.  A culture of following a process because we have always followed this process is likely to find that agile does not play well in that sandbox.  These types of corporate cultures, those companies that are most susceptible to becoming a cargo cult in their agile approach, simply do not put in the effort to change their deeply rooted culture, where it is required to change, in order to take advantage of what agile has to offer.

So how do we avoid becoming a company using a cargo cult agile approach?

Take an honest look at the company’s current culture, and recognize where the culture and the agile principles may be at odds.  Honestly evaluate the effort that is required in order to effectively change the culture where necessary.  Be painfully aware of the danger that exists in becoming comfortable with simply going through the motions.  Implement a mechanism in which agile teams that employ self-discipline are recognized and rewarded; self-discipline that is required in order to maintain sight of the goal for each project.  Embrace your team’s ability to risk and address any portions of the culture that are at odds with a team’s ability to risk for the greater good.

Make sure that every portion of the organization that’s involved in using an agile approach has the appropriate training.  When agile is taken out of context, when only bits and pieces are explained or used, it may be difficult to get the appropriate amount of mindshare required to truly affect a paradigm shift of the company culture.  Too often I have seen the tides turn against agile simply because the people being asked to use it do not have a complete understanding of the pieces that make up the whole.  When you are able to elevate the team’s understanding of the benefits and the ‘whys’ behind the ‘whats’ of agile, it will becoming self-reinforcing, which is the best possible approach to changing a company’s culture.

Is your company using a cargo cult approach to agile?  Will you be the one to ask the questions that start the discussion?  Dare to risk!