Agile Observations from the Trenches

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.

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.

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.

After training dozens of teams, I have found another disturbing trend, the trend of cargo cult agile teams.  The term cargo cult comes from the author Richard Feyman and was described in detail in his book Surely You’re Joking, Mr. Feyman!  The terms roots were even earlier than its use in his book, originally being used in his 1974 commencement address where he warned of learning to not fall into the trap of fooling one’s self.  And unfortunately, this is just what I am seeing more and more lately, agile teams fooling themselves into believing that they are truly utilizing agile.

So what is a cargo cult?

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

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

How does the term apply to an agile team?

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

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

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

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

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

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

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

When I first started providing Agile training for software development teams looking to abandon their waterfall approach, I found myself consistently working with mavericks, teams of developers looking to push the envelope on what was possible.  These teams were on the bleeding edge of innovation, and as such, they often were habitual practitioners of risk taking.  Not the risk that those of us with a project management background may have traditionally defined it as, but a simple willingness to explore the unknown in search for a better outcome, where such an outcome is not guaranteed.

Those teams from just a few years ago are no longer the risk takers they once were.  Those teams have been replaced by teams comprised of nervous individuals, afraid to do much of anything that does not come neatly packaged with a guaranteed outcome.  The willingness to risk has been wholly replaced by an inflexible adherence to metrics that measure the team’s ability to meet expectations and estimates, but say nothing about product quality and the importance of a happy customer.

Software development teams are losing sight of what is truly important.  These teams are worried more about satisfying internally defined processes as opposed to building great software and endeavoring to satisfy their customer.  And sadly I am seeing this trend on the rise rather than the decline.  In this battered economy, I am seeing teams of talented people under-promising in their efforts and estimates, so that they can minimize the risk of falling short on a deadline or a deliverable.  I am not saying that missing a deadline or deliverable is a good thing only that  I am seeing these teams behave from a place of fear because their employers are rewarding the wrong results and inadvertently punishing, or at the very least discouraging, the right behaviors.

How have we so quickly become adept at management from this place of fear?  Is it the economy that has created this fear based professional economy of cowards?  Partially, possibly, but I started seeing this trend before the economy passed the event horizon.  So what type of organization, company, culture, or management approach is cultivating this crop of individuals?  (I use the word ‘individuals’ loosely, based on the herd mentality I have also noticed.)  What is being put in the drinking water at these IT companies?  Probably most importantly, what can we do to reverse course on what is likely to become the silent killer of innovation and workplace happiness.

The answer is simple.

Failed efforts to improve must be celebrated.
Failed attempts at a new approach must be cheered.
Failed attempts at doing anything out the circle of comfort must be rewarded.
Failure itself must be de-stigmatized.
Failure as a term must be taken off our list of bad corporate words.
Failure must be redefined as the hallmark of a team on a path towards greatness.
To be great, we must fail.

Failure is a product of good Agile teams.
Failure is an absolute necessity for great Agile teams.
Failure redraws the lines that bound the area of comfort which typically define an average team’s actions, as they rarely or never act outside of this zone.  They rarely act outside of this zone because anything over this line represents effort without a guarantee of positive outcome.

For great Agile teams, this line, this ‘boundary’ defines the point at which they have the possibility of improving, growing, producing results that exceed their own expectations or understanding.  This line does not bound their actions, it simply provides measure against which they can judge their ability and extent to act outside this zone.  Great teams are defined by their ability to constantly re-evaluate and re-draw this line.  The ‘boundary’ for great teams fails to bind at all and becomes a reflection of the great team’s greatness.

When I began training teams on the tenets of Agile, I trained great teams.  Today I see average teams.  And the discouraging trend is towards average being the preference.

Now I am not all about simply pointing out doom and gloom trends as I see them, I would also like to offer a practical approach to how to stem this tide.  I stated above that we need to embrace failure.  Sure, I said that in a very specific way to elicit some response, but in truth if we, as a team, only pursue those actions that have a guarantee of successful outcome, then we will only ever produce the known.  Agile teams, with short design and production cycles can actually fail, and fail quickly, while still being successful.  Short term failures are then replaced with the possibility of long term innovation.

If you always do what you have always done, then expect to get what you always got. Agile teams embrace change and often strike out into the unknown for nothing more than the possibility that they may be able to create something greater than for which they could have planned.  Agile teams are those mavericks from the past.  They are the explorers.  We must encourage breaking the chains that I see are binding teams today, teams that see their boundary as insurmountable.  We are creating teams, environments, and cultures of mediocrity.  Nothing great was ever created by individuals that made their decisions from fear.

We are either growing or dying.  We are either deciding to do great things or deciding to shrink our influence.  The decision is ours to make.  And I know what I have decided.