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.

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.