Agile Observations from the Trenches

Over the past several years I have racked up more than just a few frequent flyer miles.  If my math is correct, I think it is the equivalent of flying from the earth to Mars and back 228 times.  Of course don’t trust my math, I made up that figure to represent not the true number of miles, but what it feels like sitting in these narrow seats week after week, and doing your best to think of new and interesting ways of passing the time without having to make small talk with the guy sitting just millimeters away (I find intently reading a book while holding a highlighter really does the trick, and I have a feeling that it is the power of the highlighter that says to would be conversationalist ‘hey, this guy is so serious about what he is reading, that he is planning on coming back to review it later.’)  It’s not that I don’t enjoy a nice conversation now and again, and I have had plenty while sitting on a plane, it is just that after a few days standing in front of a room of people who have come to one of my classes, I have lost much of the motivation it takes to want to sound interesting to a stranger, especially one that did not pay to hear me speak:)  And I should also point out that I write this while sitting in seat 10C on Delta flight 1131, and although I do have a neighbor in 10A, the one seat buffer seems to keep me from having to engage, thus allowing me to post this entry.

Now of course I didn’t pay for the inflight internet to complain about airplanes, the narrow seats, or the uncomfortable forced conversations that happen on them.  I am writing this because in the fast few weeks, I have had multiple experiences with several different teams all struggling with the same issue, how to transition to an Agile approach.  These were not new experiences for me, in fact I have heard these same songs being sung since I entered this training business and focused on Agile transitions.  The difference is my evolving understanding as to the cause of the difficulty and the nature of the pain these teams are experiencing.

CHANGE IS TOUGH!

I just wanted to get that out of the way in case any person or team was thinking that their transition was going to be easy.  And let me be clear, the change I am speaking of is not the ability to understand a new process or a new approach.  It is not whether a team is able to identify or understand the underlying reasons for the change or clearly defining the organization value stream associated with their development efforts.  These areas (and more) all represent something that can be taught, something that can be learned, they represent new knowledge and techniques for defining the unknown.  My classes cover these areas in depth.  So if not these areas, then what?  What is this difficult part of making a transition of this kind?

The culture. The undefinable piece of our organization that makes us unique, makes our cogs turns, allowing (forcing?) everyone to share the same values and expectations of action/processes/methodologies/etc.  It is what makes us ‘us’.

Here is what happens most often when a company realizes that they must update their approach for product development to one utilizing an Agile flavor (or any other change of this magnitude.)  The senior management identifies with the advantages that the change will offer, they read white papers on how other companies (including their competitors possibly) are utilizing the new approach to make advances in innovation, efficiencies, cost savings, etc.  They send their team to get the requisite training.  The team gets excited, returns to the company, and begins to operate in a way that they believe will make the improvements offered by the change.  But then something happens, things are not as easy as they had hoped.  The new approach seems to uncover problems they weren’t aware of previously, the new approach seems to cause problems, the new approach is actually slower than the old approach, the new approach seems like more work, the new approach may not be working at all.  The excitement, the momentum for change, the forward motion that the team experienced early on has now slowed, and there is growing sentiment to go back to what they previously were doing.  ”It may not be great, but it kinda worked and we knew how to do it” they might say.  And before the team knows it, the old process has returned, warts and all.

This scenario is a representation of a company culture that is oscillating between two structural tensions pulling in opposite directions.  The companies that follow the above example likely have a culture that favors predictability, stability, metrics, milestones, and plans, thus creating a tension in their organization that keeps them to a plan based approach for development.  In the above example, the change identified might have been introduced with the idea that innovation, responsiveness to change, competitiveness, and an amount of realistic uncertainty will move the company in a positive direction.  Unfortunately, this also creates a structural tension within the organization, but pulling in the opposite direction, thus resulting in structural oscillation.  The worst part of this story is that the company above will likely go through many cycles of the scenario, each subsequent scenario and its inevitable failure undermining the next attempt to change the company in a positive way.

Sound familiar?  It likely does, because it is a common thing to hear people in organizations like this say “oh, here we go again, the latest fad” when a new initiative is introduced.  And there is never a shortage of new initiatives, is there?

So what do we do?  How do organizations make lasting change?  It is possible, but rather than change to the superficial wrapper of what it is we are doing in a top down approach (thus opening the likelihood we will become nothing more than a Cargo Cult Agile team), we must address the structure that affects the overall direction of the company, the culture.

I will address this idea of culture as a primary component of our change efforts, but it will have to be in a future post, as I just got word from the captain, we are starting our descent.  Looks like I may have to have that conversation after all, my neighbor just asked me about my blog.

Until next time, let me know what you have done to affect a positive, lasting change in your company’s culture.  I would love to hear war stories, even disaster stories if you got em, I know I do.

I write this post on a flight to Philadelphia, the city that hosted a special session of the Continental Congress, charged with the monumental task of drafting the Constitution of the United States.  It got me thinking about the historical significance of this effort, at least as we reflect on it today.  But during the summer of 1787, when this precious document was drafted, there was not the focus or import placed on the task that we might imagine there had been.  In fact several states failed to send representatives to assist in the creation of this document, a document that would be the foundation for the creation of the greatest nation on the planet.  Let me repeat that, several states failed to send delegates to help craft the document.

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

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

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

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

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

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

Bill Gaiennie

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.