Agile Observations from the Trenches

In some medieval cultures, cows were sacred, never to be killed for food or even used to assist in the plowing of fields.  These sacred cows enjoyed a serene life, having free run of the space within the community’s gates in which they resided.  These cows suffered no enemies and were generally able to lead long lives, ultimately dying simply of old age.  They were never challenged, except in very rare circumstances, as was the case one spring in medieval Europe…

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.

Every time the topic of an Agile Process Maturity Model (or APMM for short) comes up, I simply sit back and watch the backlash grow to a furious pace, then see the APMM proponents slink off.  But here we are again, seeing the growing trend of APMM discussions, but this time, it looks like there are some pretty big players backing the movement, including a division of IBM.

As I was poking around the web and polling my Twitter folks, I found a couple of interesting links.  The first was a short post on InfoQ by Scott Ambler (dated June 15, 2006), titled Has Hell Frozen Over? An Agile Maturity Model? And then, just a single Google search later, I found the IBM website that showcases the work that has been put together in favor of this APMM.  The crazy thing?  It too was authored by Scott Ambler.  Now, don’t go misinterpreting what I am saying here, I do not think Scott is crazy, afterall 3 years have passed between the two posts, but I do find it a little peculiar when big business (like IBM) partners with an industry expert in an attempt to capitalize on any growing trend.

For those of you that have spent any amount of quality time in the Agile trenches, then you will likely know what I know, which is the idea that an overly burdensome process can easily sap an Agile project of any power and efficiency that may have been there otherwise.  Processes are like governmental positions and agencies in that once they are created, they very rarely go away.  What we have succeeded in doing with Agile is having the conversation about this truth about process and then encouraging the courage required to eliminate that which does not add value to our efforts.  Lean and mean is the way to go, but this is not an approach that is likely to play friendly with any type of review approach that will judge and evaluate success based on adherence to a pre-defined process.

Do I think that APMM could single-handedly ruin the Agile movement?  No, but as far as I understand it in its current form, I do not think that it is going to help teams become any more proficient in their approach or deliver a better product.  I believe that the man behind the curtain with this whole movement is pushing his levers in a poorly veiled attempt to appeal to large organizations that find value in the certification designation that they get to display proudly when they pass “the test.”  I have worked with more than one organization that was currently still stuck in this trap as it concerned their CMM designation.  These companies spent more time and effort worrying about keeping their current level, or moving to the next, to accurately evaluate if what they were doing and what they were delivering translated into true value.

Uhhhg, this may simple be a battle not worth fighting.  Let those companies that want their certificates showing they are at X Level of APMM go for it.  Let them spend the money.  Let them do all of this and then at the end of the day, let them continue doing the same things they were doing before the set out to rank their approach in terms of the APMM.  I do suppose that there is going to be a lot of money out there to be made for consultants who specialize in taking companies to higher levels of an APMM designation, so I might as well surrender to the movement, and then plan buying a bigger mattress under which I will stuff all of this new consulting money I plan on making.

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.

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.

I had big dreams when I started college.  I had always wanted to go to law school, for nearly as long as I can remember, throughout grade school and then into high school, my plans were always that following college, I would enter law school.  As I approached college, I had to get more serious about my ultimate plans to make it into law school, so I had a long discussion with my father, during which we both realized that there were far too many lawyers graduating from law school and finding themselves unemployed with a law degree.  We concluded that in order for me to make it in the field of law, I would need to specialize.  In preparation for this specialization approach, I decided that I would like to try international law, and toward that decision, I enrolled in a Japanese language course.  It only took a single class for me to declare my major as East Asian Studies with a concentration in Japanese (this was the official UCLA equivalent of a Japanese major.)  Four years later I graduated with this major, but never made it to law school, never even applied.

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.