Agile Observations from the Trenches

Agile Observations from the Trenches is sponsored by Davisbase Consulting, which offers a wide range of consulting services, Agile training courses, and customized services for organizations looking to adopt an Agile approach to their IT development efforts. This blog is written by several trainers that primarily work with teams looking to implement or improve their Agile approach to software development. To find out more about who is behind the blog, please view our 'About' section.

Welcome, and thank you for taking the time to read and participate in the discussion.

Flying just a few feet off of the wings of the pilot in front and to the right of him, this skilled pilot was determined to keep a tight formation. And he was not alone in his efforts and highly honed flying abilities, as every single pilot in his entire squadron was similarly adept at maintaining this tight formation no matter the direction, the weather, or even the specific order in which these aviators organized. The formation would have looked impressive to anyone observing from the ground, but it wasn’t a formation used to impress observers, it was utilized because it worked. By maintaining this flying organization, each member of this flying contingent was able to benefit from the lift created by the pilot off of his wing, to the tune of a 71% improvement in fuel consumption. The exception to this economy of course was for the sole lead pilot, which did not benefit from having a lead aircraft providing a boost of lift. So to account for this, each member of the flying team would rotate to the lead position at regular intervals so that they could ensure that every member would share the burden for a portion of the total flight time.

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.

A bit off topic here, but as I was roaming the vast halls of the internet today I ran across a new social networking type of tool called Audioboo.  It works much the same as others, providing a technology to share, interact, and connect with friends and collegues over the internet, but is much different in the way that instead of simply capturing text, it captures audio.  You sign up for the service (free, which is in keeping with the rest of the category), then you can download the application onto an iPhone and you are all set.  [For those of you without an iPhone, they also allow uploading of audio on their sister site PhoneBoo, which costs nothing, other than what your provider charges you for the call.]

From your iPhone or any other phone, you simply record anything that you would like to share, up to 3 minutes in length.  Then once you are done, you upload the audio, and voila! everyone that you are connected to is able to listen to your audio share.  If you are doing this from your iPhone, it also encodes location data, showing where (on a map) that you recorded the sound byte.  Optionally, you can also snap a picture to show along with your audio.

At this point, I am not certain if I will find enough value in this tool to use beyond the initial ‘wow this is cool’ phase, but nonetheless I find the tool innovative.

Which brings me to another topic that seems to continue to be all the rage, Twitter.  Now, there is nothing that I could write that would add any new insight into this seemingly unstoppable technology, in fact I am almost embarrassed to say that I have not been able to see enough value in Twitter to use it consistently. In fact, a colleague of mine and I just a conversation a day or so ago to discuss possible business applications of the service.  I know that businesses out there must be using Twitter in some of their marketing, sales, or simply communication efforts, but I have not really seen any that appear to be more than just gimmicks.

But I am coming around to Twitter, it has just been slow.  A couple of factors have began to change my mind concerning whether I should be using Twitter more consistently.  First, while looking over the analytics of the traffic making its way to this blog, I am seeing more and more traffic being driven by Twitterers (or is it Tweeters?)  If I am going to grow a readership that utilizes Twitter, I suppose I should jump into the fray.  The second factor, one that seriously surprised me, was the results of a survey conducted by LinkedIn that found more businesses identifying Twitter, more than any other competing technology, as the service to master in order to be successful in today’s business climate.  A great write-up on the survey was completed by ReadWriteWeb and is worth a read if you have a few minutes.

I am soliciting feedback from you…share how you are utilizing Twitter, your experiences with the technology, and if you believe it to be more than a gimmick in its offering.  As I develop my own ideas, I will share them here.

And if you would like, follow me on Twitter, username AgileAdvisor.

On a warm August day in 1768, explorer James Cook set sail from England aboard his ship, The Endeavor.  On board were 94 crewman and scientists, and their mission was to find the fabled ‘Southern Continent.’  Early map makers in 1570 claimed that there were two major continents at each of the earth’s poles, and Cook was to discover this southern continent and claim it for England.  Although Dutch explorers had unsuccessfully attempted to find this mass of land in the early 1700′s, Cook was certain that his attempt would result in landing on these undiscovered shores.

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.

Elephants can easily grow in excess of 5 tons each, tearing through trees, brush, and even houses if they get in their way.  These lumbering giants are roamers by nature, and typically care very little about what obstacles are in their way, as most obstacles they find in their environment are no match for their own gigantic size.  Keeping an animal like this in captivity can be quite a challenge.  Perhaps a zoo that has the proper facilities and staff can keep these gentle giants confined, but when an elephant is born to a poor farmer on the plains of Africa, the challenge would seem to be much greater to do the same.  But in reality, it is actually quite easy.

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.

Our development team did not set out to build the most expensive printer stand in the history of printer stands, but build it we did.  We actually set out to build some cutting edge handhelds loaded with bleeding edge software that would enable a more immersive retail shopping experience (I won’t give too many more details, as I don’t want to name names.)  Here is the quick story how we made history (that is if you are talking about the history of expensive printer stands)…

It was a great day when I was informed that I would be managing the team that was selected to deliver a very forward looking product for one of our largest retail customers.  We were excited, nervous, and wanted to make sure that we got this right, as this was not only a project that could seriously boost our careers, but it was a product that could possibly get some major exposure.  In preparation for this project, we did what we thought best to do in a situation like this, we prepared.  In preparation for our preparation, we prepared again, and then we planned, and then we planned on doing some more preparation before our final planning session, before the kickoff planning session with the customer.  I could go on and on, but I think it is clear that we spent a good deal of time making sure that we were as prepared as possible before the project was even officially started.

The project kick-0ff meeting with the customer went flawlessly, and this was due (in my opinion) to two major factors.  First, we were prepared (and by we, I mean the development team), having done the requisite research into how we were going to deliver the product, what was the most appropriate technology for the development of the product, and what we would need to know and what we would need to be good at in order to meet the customer’s expectations.  Second, the customer was prepared, and was able to very clearly identify the specific requirements for the product.  They had done a lot of research into the needs and wants of their customers, and then very carefully translated that information into what the product should look like in order to serve those needs.  We, as a united team, as a single unit, as customer and vendor, were ready to change the retail world, and it was with that level of excitement that we launched our project.

We had originally estimated that the requirements gathering phase for this innovative product to take between 1-2 months, but here we were 6 months later, just wrapping up the specifics of the product.  And when I say specifics, I mean detailed, technical specifications on each and every nook and cranny on the hardware and every technical crevice in the software.  We were so well planned, and had an equally detailed project plan to match, that we could say with relative certainty when we would be taking lunch months later.  We had solidified the next 10 months of our lives into daily bites of planned progress, and the plan was our bible, our map, our GPS device that was going to guide us to a success, fortune, and fame.  The plan was done, and the plan was good, so off we went.

The plan did guide our efforts well.  Along the way we diligently hit each of our milestones, our sign-offs, and our module demonstrations.  We were, in short, meeting every project expectation and constraint,  and in the end delivered ahead of schedule, on budget, and even incorporated some small additional functionality.  Speaking solely in project terms, we did what was traditionally thought of as the impossible, and it was good.

The good times our team experienced, the excitement of relishing our success, was soon dashed by a much greater failure.  Although ‘we’, as the development team, were successful in meeting our obligations to the customer, no one was keeping an eye on the turbulent market conditions to ensure that the product we were building would have an audience when we were done.  This ‘market viability study’ was done in great detail during the project justification phase (the “should we spend this money to build this product, and will we make money doing it” phase).  But once that initial assessment was done, it was never revisited, and the product we ultimately delivered did not have the market that was anticipated a year earlier.  In fact, the market had changed substantially, but no one was watching.

If you haven’t guessed already, this happened quite some time ago, when I followed a waterfall type of approach to project management.  We followed the mantra, plan the work and then work the plan, which may work some of the time, but completely ignores the realities of a rapidly changing marketplace and a competitive landscape.  Our development team, and even more painfully, our customer experienced first hand something that I will never forget…

We did have a brilliant product.  But that brilliant product existed only in the imaginations of those with the idea to build it.  If we could have snapped our fingers and instantaneously had this product available, it likely would have been successful, but we couldn’t, and it wasn’t.  It took time to plan and then build this product, during which time the anticipated customer base that we believed would want our product had changed their needs and wants, essentially killing our product before we even completed it.  The hand held devices and all of the project documentation eventually made their way into a large cardboard box, which shortly thereafter was used to support my personal office printer.  It was somewhat devastating the day that I realized that what we had ultimately built and delivered was a $788,217 printer stand.

What does building the world’s most expensive printer stand have to do with agile teams?

Plenty.

Agile teams recognize that in order to truly define our efforts as successful, we must to do more than simply meet budget, schedule, and scope obligations.  We must keep our eye on the bigger picture, which means that we may need to change course mid-way through a project.  We must do this if we believe that the ultimate destination for our product will be better.  Had we kept our eye on the marketplace, had we been more keenly aware of the shifting winds that were all around us, we could have responded by modifying our design, usability, and primary use of the product we were building.  We could have had a chance to meet the needs of the market with a product that suited those requirements.  But the only requirements we focused on, the only requirements that guided our efforts were those requirements defined months before we would ever be ready to deliver.  The world was changing all around us, but no one cared to watch.   Or perhaps even worse, no one watching cared.

Agile teams embrace change. Change happens, and when it doesn’t, it is more likely that you simply are not in tune with change that would guide you to a better result.  I remember back in those dark waterfall days thinking that if changed happened, it would be bad news, something to worry about.  My approach in today’s agile environment is just the opposite, if I have not been aware of any change throughout the course of the project, I worry that I may be missing the changing needs and wants that will translate to a more successful product.

You may have experienced building your own exorbitantly priced printer stand, but don’t worry.  These experiences that don’t kill us (or our careers) only make us stronger and smarter, so long as we listen to what our experience is telling us.  My experience was a great instructor, showing me clearly that in today’s rapidly changing software development environment to ignore a shifting market landscape, to believe that a static world is waiting while we develop, or to pretend that change doesn’t happen, will only result in something less than the success that may have been possible.  In order to survive and thrive, we must adapt.

In order to truly be agile, we must expect change to happen.  And when it happens, we can greet it with a smile, knowing that a better outcome is now possible.

I simply wanted to snap some pictures of my dogs running around the park last weekend.  As I was about to round up the dogs to head to the park, I went to grab my camera, but then realized that I had left it at work.  So I jumped in the car to run by my office to grab the camera, but realized that I didn’t have a key to get into the building.  I knew that a co-worker always had a key, so I started to drive to his house, but then realized that the last time I borrowed something from him, an exotic suit, I never returned it because I had accidentally ripped a pretty big hole in the jacket.  I knew that my co-worker wouldn’t trust me with the office key if I didn’t return the suit, sans hole, but I had not been able to get it repaired because it was made out of yak hair, something I wasn’t even sure I could get.  I contacted a tailor who would be able to repair the suit, but wouldn’t be able to do it unless I was able to provide a supply of yak hair so that she could weave it into a fabric, and then from there use the yak fabric to repair the yak suit jacket….

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.