(Hint: You might want to maximize the screen in order to see the elements of the slides I display.)

I often stop and reflect on the benefits of the two major Agile methodologies, especially Scrum and Extreme Programming (XP).  There is some amount of beauty and perfection in these methodologies.  Both are found on Agile Principles and Values, but tackle the beast of software development from different perspectives.  Scrum is like a great seven-course meal.  We have our Product Owner, Scrum Master, Team, Sprint, Daily Standup, Demo, and Retrospective.   All seven pieces are critical and you can’t just leave one out. Doing so would be the equivalent of a seven courses meal with only 4 or 5 courses.  XP on the other hand is like a great recipe.   Every practice feeds off one another just like every step in a great recipe is crucial to each and every other step.  Skipping a step or leaving out an ingredient is going to make for a really bad experience.  I’ve gone back and forth over time debating if the Agile evangelists are really right when they say you have to adopt all of the XP practices to really be successful. I have come to realize that they’re probably not too far from the truth, each of these practices really feed off one another.  Pairing forces developers to collaborate at the lowest and simplest level, 2 people.  We must have tests to provide a safety net for refactoring.  Test Driven Development (TDD) insures we have the tests by doing them first. Once we have tests we can leverage them for continuous integration and as a more effective and executable documentation. Each practice supports one another and is marginalized without these supporting practices.   You can’t just decide to take a few of these practices and expect them to work in harmony.   You got to follow the recipe to create a great seven-course meal or a great main dish.   Failure to do so will leave a bad taste in your mouth like crème brulee and hot sauce.

In the 1970′s, as projects grew larger and larger in scope, there was a concerted push to ensure that costly changes late in a project cycle were avoided at all costs.  These “defects” of process were identified as common enemies to a successful project lifecycle, and were one of the primary motivations to move to a more structured approach of project and product management.  Out of this effort grew what would become known as the “Waterfall Model” of product development.  This approach called for all planning, extremely detailed planning, to be conducted up-front, before any actual development work was started.  The thought, very rational at the time, was that any time spent up-front in initial planning was an investment that would pay dividends compared to a lack of detailed initial planning that could ultimately yield many costly changes late in the cycle.

Times were different then.  At that time there was a need to ensure that every last detail was known before beginning an expensive development effort.  Most of the projects that employed this methodology during this period were of a non-complex nature.  In simpler terms, they were more closely aligned with construction types of efforts as opposed to the complex nature of software development, especially considering the software development done today.  Why would I refer to construction efforts/projects on a non-complex nature?  Because back then success was generally a product of how closely the execution of the plan matched the plan.  It was thought that the final product of these efforts should match the original plan precisely, and any major deviations from the plan were categorized simply as defects.  And rightly so.  Construction can take this approach.  In fact, construction types of projects should take this approach.  These types of projects should not evolve over their construction efforts, as this may yield a poorly delivered product or a deliverable that does not match the expectations that were set during the planning efforts.

Software is different.  Software is knowledge work.  What we are building is generally based on a description from our customer of a product that does not exist.  When utilizing a waterfall approach to project management, our attempt to capture this description of an imagined product from our customer takes the form of a detailed specification.  And in our effort to reduce the perceived risk of change, we capture that all important signature to ensure that we discourage change along the way.  Even for software, this approach once worked, and worked well.  But as software became more complex, more innovative, and as product refresh cycles shrank, the need to be increasingly more responsive was seen as a compelling competing force working against efforts to guard against mid-stream product specification change.  As markets shifted, as companies competed, the waterfall model was quickly becoming a dinosaur in a world that no longer favored the large, lumbering behemoth that waterfall represented.  The pre-programmed death of a once useful approach was being triggered.

Waterfall, although not dead, is laboring through what seems to me to be a labored death march.  And although this is an agile blog, you are not going to hear me herald agile as the final, ultimate victor.  Perhaps if it were only a match between the two development approaches, but it is not.  The lifespan of the development lifecycle will go on and new players will emerge based our learning and understanding that has evolved along the way.  And as waterfall dwindles in effectiveness when applied to software development projects, agile is gaining a foothold.  Agile exploits today’s realities, just as waterfall did when it was king.  Waterfall is a victim of its own apoptosis.  It was destined, although not designed, to be obsolete, preordained to die the moment Winston Royce inadvertently wrote it into being.  Agile’s birth benefits from the pain that has been caused by utilizing waterfall in world that cannot wait for the long cycles that waterfall requires.  Death is always spurned by, and simultaneously allows for, rebirth.

Welcome to the world Agile. You have been around for awhile now.  You are becoming more and more well known.  You success has been widely documented.  You are past the dreaded chasm that many new beings are never able to cross.  You are now mainstream.  You are in your prime.  It is possible that your best years lie ahead of you.  It is possible that your best years are behind you.  But make no mistake, your own clock is ticking.  But that is the beauty of nature, every apoptotic cycle not involves the death of one being, it provides the energy for the creation of another.

I make my living providing agile training and coaching.  I am extremely passionate about the type of change that an agile transformation can mean to a company.  I have seen incredible results from the principled based approach that agile represents.  I hope that agile stays around for a long time.  But not longer than its usefulness.  And that is one of the great tenets of agile.  In the DNA of these agile principles is the idea that our organisms, our teams, our approach, our methodology, our framework, our everything should always be evolving as we learn more, as we experience more, as we become more.

It is truly a beautiful aspect of agile that from it’s own birth it recognizes that in its current form it had already predicted its own death.  But this is what makes agile a distinguished and impressive approach to product development and delivery.  Agile, I am your biggest fan, but I will not cry when you are gone, for your existence supplied the knowledge and energy for whatever is coming next.

I frequently work with teams of people from a range of companies, industries, and backgrounds, and its during these sessions that I think back to those larger thoughts about how we experience our lives as individuals and as members of teams.  What makes some teams click, thrive, and deliver?  How do some groups of people truly share a common goal and work creatively to achieve it?  Why do some groups of people seem to only suffer through projects and then deliver dismal results, consistently?  What is the definable difference between the experiences of these different groups?  Why are some people happy with their job, their company, their project, their healthcare, their family, their car, their house, their spouse, their life, while others would seemingly choose to be dissatisfied no matter what they may be blessed with?  Where are the connection of neurons responsible for our ability to be happy and productive on a team?  And does this ability to choose happiness relate to better relationships and results at work?  How do I grant the gift of effortless success and indomitable growth to teams that struggle endlessly to achieve even modestly positive results?

To help me answer these questions, I turned to an insightful book The Wisdom of Teams: Creating the High-Performance Organization. In the book authors Katzenback and Smith define a team as “a small number of people with complementary skills who are committed to a common purpose, performance goals, and a common approach for which they hold themselves mutually accountable.”  Although I agree wholeheartedly with their definition, the book did not satisfy the curiosity I had about what components make certain teams tick and others tock.  I needed an understanding at a deeper level, I needed to examine the DNA of teams.  So instead of reading more about teams from a business perspective, I instead looked into those double helixes that seem to determine everything about us, our very own DNA, to see if any insight could be found.

The human genome project promised to finally unlock the secret recipe for what makes us who we are.  And like so many other great scientific promises of the past, it failed to yield an answer to everything, but rather provided a perfect foundation for even greater questions.  Although our DNA provides the building blocks for our physical being, it cannot alone explain the curiosities of individuals, from our personalities, to our attitudes, to our propensity for success, or our ability to trudge inexorably to failure.  This mysterious exclusion is expressed effectively in the observation of identical twins, where the DNA encoding remains identical, but where nearly all else is unique, especially when the brain is examined.

Like our DNA, we often cannot choose the members that make up our team, but equally similar to DNA, it is not simply the members of our team that pre-determine our possibilities.  Too often I hear individuals complain that consistent success would be possible if only they were assigned to the right team or if the right team were assigned to them.  This superficial failure of perspective can often become a self-fullfilling prophecy, yielding the expected negative results as a consequence of subconscious actions driven in support of the consciously expected outcome.  As with many mysteries of life, perspective and belief are more powerful than we allow ourselves to consider.  We seem to be more content to apply unreasoned reasons to our perceived consequences rather than seeking to drive meaning from those things for which we could have affected the outcome.

Recent discoveries in the world of science confirm the notion that we are more than our parts, both on the individual and team levels.  These scientific revelations point to a beautiful aspect of life that affirms that we are not limited by our structure, but are allowed infinite possibilities through the wonder of chaos; an inability and impossibility of perfectly predicting results based solely on observing conditions, thus free will is born and an infinite number of possible minds follows.  Author Jonah Lehrer states “that [this] is the triumph of DNA; it makes us without determining us.  The invention of neural plasticity, which is encoded by the genome, lets each of us transcend our genome.  We emerge, character-like, from the vague alphabet of our text.”  And as is true for individuals, it is equally true for how effectives teams can be, regardless of their own DNA, regardless of the individual components of the team.

Supporting these ideas, in a 2002 Science paper entitled “Stochastic Gene Expression in a Single Cell” Michael Elowitz of Caltech demonstrated that biological “noise” (a scientific synonym for chaos) is inherent in gene expression.  His results further solidified the unfolding scientific belief that it was this “noise” that held most of the possibilities for emergence in design for organisms, which contradicted the earlier collective belief that natural selection alone held this potential.  These discoveries, by extension, illuminated the idea that without this inclusion of chaos, then every cell that was created by the same DNA would operate, behave, and produce the same results, but we know that this is not the case.  In fact, without this beautiful inclusion to our evolution, we would not experience the diversity of life that we do.

Digging more deeply into what constitutes success in these complex adaptive systems (organized as teams), yields the result that diversity in experience, knowledge, personality, and drive is what allow them to truly excel.  The equivalent in nature was captured by Darwin when he wrote that ”the more diversified the descendants from any one species become in structure, constitution, and habits, by so much will they be better enabled to seize on many and widely diversified places in the polity of nature.”  A team’s diversity is one its greatest strengths, so long as the diversity is expressed and exercised regularly.

Teams are not doomed to failure as an inevitable consequence of the composition of it’s members.  Similarly, individuals are not merely limited to the sum of their specific DNA coded sequences.  And if these statements are true, how do we then affect better outcomes from both teams and individuals?  Just as individuals are formed by their experiences that shape their neurons, bringing temporary neural order to chaos, so too can teams also allow their experience to help bring consistency in results to their previously unpredictable outcomes.  But in order to make this happen, teams need two very important components in place: 1. An ability to clearly define their current state set against their preferred results (this allows the team to define the state of dissonance between reality and possibility, thus developing creative tension in the structure).  2. A mechanism that allows the team to utilize experience to shape future team decisions.

I am a firm believer that:

- Given the opportunity, most people would rather succeed than fail.
- People are very well aware of organizational constraints that limit their ability to achieve and succeed.
- Most people feel limited in their ability to affect change in their job.

So what is the answer?  How do we elicit better results from our teams?

If you are still with me this far, then it is only fair that I provide you an answer, right?  Unfortunately, as much as I would like to, I cannot provide an answer, only a direction.

The potential source for your organization’s power lies in the unexplored richness of experience and understanding held by your people.  You may believe that your organization actively solicits input and feedback, but if your organization is like most, you don’t, at least not well enough.  You will know when you have breached the barrier that separates average teams and corporate culture from their extraordinary equivalents.  You will know because you will discover the roar that exists on the other side of silence.  Do not dig unprepared for what you may find, the roar is often deafening.

Seeing this huge gap between team types begs the obvious question, what is the difference between the teams?  Is it company size? No. Is it the industry?  Nope, seen great teams in every industry including DoD, government, tech, and finance. Is it the goodies provided for free in the kitchen?  Maybe, but I don’t think so.

So what is the secret sauce of these hyper-productive teams?

As you might guess, it is not any one thing, but a combination of many different factors that all support the single-headed direction to support the creation and continued operation of a highly productive team.  So what are the ingredients?  Here is my unscientific, and definitely un-exhaustive list:

1. Great people.
   We cannot pretend that only process matters.  Spend any amount of time digging into great teams and you are likely to find a fair number of great people, people that would be great on any team.  Get enough of them together and you have a good shot at a great team.
2. Organizational culture supportive of making mistakes in pursuit of greater return results.
   Teams that are comfortable at making mistakes often find that they also produce extraordinary results.  True success is often comprised of multiple failed efforts that did not sink the team, but rather allowed the team to learn things they could not have learned otherwise.  Working within a corporate culture that recognizes this is a key component to super teams.
3. True team based delivery culture (which means this is also taken into account during things like individual’s annual reviews.)
   Teams that recognize that we are not simply individuals working in close proximity, but a team where we must all be engaged with one another’s work.  I tell teams looking to achieve amazing results that each member of the team must care as much about their neighbor’s work as they do their own.
4. Team members that share a sense of purpose, vision, and passion for their work.
   If team members believe that they are contributing to something greater than their individual part, then they will care at a much greater level than their individual contribution.  Work to ensure that a team can share this vision and goals begin to shape themselves.  Better yet, teams begin to manage their own incremental improvement, otherwise know as the team holy grail.
5. A company that cares as much (if not more) about their employees as they do about their customers.
   At the base of it all, we must feel appreciated at our place of work, or we may not be able to cobble together the above components.  Companies that treat their employees as commodities will likely only experience amazing, hyper-productive teams sporadically, rather than as a expected result of a team-based product development environment.

[Let me state clearly, this list could likely be much, much longer, so please feel free to add to it in the comments. Whole books can, and have, been written on the subject.]

A the Heisenberg Uncertainty Principle states “any system development activity inevitably changes the environment  out of which the need for the system arose” so true is it that any team activity will likely change the culture out of which it was born.  Corporate culture, although seemingly unchangeable when our teams operate seemingly at its mercy, is always in flux, as this cultural effect evolved not from proclaimed edict, but the work done by teams and the resulting response from the company in which they operate.  Changing this culture to enable and encourage hyper-productive teams is a joint effort from the great team that seeks to produce extraordinary results and the company that chooses to support the behavior that these teams exhibit.  Although it sounds like an easy choice for companies to make, you would be surprised just how often I encounter organizations that seem to want to thwart these great teams.

Have you had the pleasure of working on a team that was hyper-productive?  One that truly exemplified the notion that the whole is greater than the sum of its individual parts?  What was the secret that you found to be the linchpin to success?  Did you notice that happy teams produce better results?  Did you notice that teams that have fun together are able to more easily maneuver around obstacles that might otherwise sink an average team?  I hope so, because it is these experiences that will continue to push me to better define what those magical, secret ingredients are for those teams that define what it truly means to get work done.  And as my friend Rod Behbood says, “Do Work Son.”

Happy Easter everyone!

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.

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

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.

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.