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

Here are some of the details:

Website (and Registration): http://www.southernfriedagile.com

When: Friday, July 23, 2010. 8:30a – 4:30p

Where: The Crowne Plaza Charlotte Hotel. 201 S. McDowell Street, Charlotte, NC 280204

How Much: $49 (super cheap!!)

Twitter Hashtag: #sfa2010

Want more information: Go to the website for a list of sponsors, speakers, and the sessions currently scheduled.

See you there!!

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

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.

This highly skilled team of aviators recognized that they could not possibly fly as far or as long without teamwork. But this spirit of teamwork did not end with the decision to maintain an efficient formation. They recognized that in order for each of the pilots to be safe, they would need to take care of each other, even when disaster struck, which it did one brisk autumn morning…

The morning had been uneventful, each of the team’s pilots maintaining a tight formation, and a vigilant eye on the ground, because on this particular morning, they were traversing enemy territory. And even though this was a dangerous mission, this mission was much like most of their other missions, as they often were forced to travel over possibly hostile terrain. But unlike most other mornings, a trailing member of the formation was struck, by what no one could be sure, but struck nonetheless, and within moments, his ability to continue flying was affected severely: he was going down. He didn’t have a choice to eject, but rather piloted his disabled craft safely to the ground so that he could assess the damage. But as experience would show, being on the ground where he was much less maneuverable, he was at a greater risk of attack. In order to keep a member of their team safe during emergencies such as these, two fellow pilots also descended from formation, landing near the downed team member, and provided protection while repairs were made. These guardians would stay by the side of the disabled pilot until he was ready to fly again. To this fleet of pilots, teamwork meant never leaving a fellow pilot behind. After a short while, the downed pilot was able to successfully repair his vessel and all three took back to the air, rejoining their squadron. Alone, the pilot may not have survived the ordeal.

This is a true story, although it is a story that likely first took place thousands of years ago. And it is a story that continues to play out even today. You see, the pilots in the story above were not the pilots you may have been thinking of, these pilots were geese. Geese offer an incredible example of teamwork and how teamwork enables each member of the team to achieve more, travel greater distances, and weather more intense emergencies than they would survive alone. Geese use this tool of teamwork because although it requires a commitment to something greater than each individual, it repays that commitment with many more benefits not available without this pledge of membership.

So what do geese flying in formation have to do with Agile teams?

Plenty.

I would venture to guess that no company in existence would openly say that they do not believe in teamwork.  I would further venture to say that most of these companies would state firmly that their teams are very good at demonstrating team work in the projects they undertake.  But the truth of the matter is that most teams rarely demonstrate the type of team work that produces results proving the possibility that the whole truly can be greater than the sum of the individual parts.  The word ‘teamwork’ has unfortunately been reduced to nothing more than a term on the balance sheet of requirements for a group of project associated individuals; a definition never verified, never authentically encouraged by the organization, but believed to exist nonetheless.  It is a word that has lost its power.  It is routinely applied to describe a group where the group behavior does not merit its application of meaning.  It is overused, under-realized, and misunderstood because of each of these are true.  And yet only a small percentage of ‘teams’ out there truly endeavor to seek the rewards that come from achieving a level of performance and professional satisfaction that is the byproduct of individuals that sacrifice their distinction, their difference, and their dissimilarities in their pursuit of that which is greater than any one person.  They pursue the quotient that is achieved when individuals become teams.  When individual output transforms into teamwork.

Agile requires teamwork in the truest sense of the word.  Agile processes reward and recognize good team behavior in the spirit that good teams can produce great results, and as teams mature, great teams can produce extraordinary outcomes.   Don’t believe me?  Then let me pose a question to you…

Have you ever been a part of a team where everything seemed to click?  Where if you had an issue, someone on your team was there to help almost before you were able to ask?  Have you ever been on a team where the work seemed less like work and more like an expression of your and your team’s passion and energy?  If so, then you are not alone, as most people have actually had the experience of achieving this level of team maturity that results in true teamwork.  If you were not able to relate, then it is up to you to create this atmosphere with your own team, on your own project.

But before we can truly become a team, we have to also address the flip side of the coin, and that is the dysfunctions that can easily sink the most well intentioned ship of individuals who set out to discover the holy land of team performance.  Patrick Lencioni did a very good job of identifying these major areas in his book, The Five Dysfunctions of  a Team, so instead of reinventing the wheel (or the team), let’s use Lencioni’s model as our foundation.

Dysfunction One:  The absence of trust among the team members.

I think that I can safely say that if you do not have trust, you do not have anything…at least you do not have anything so far as it relates to creating a true team.  What do you have when your team members don’t trust each other or don’t trust you?  You have a group of individuals working in close proximity, but you do not have a team.  You also have a group that is not able to focus their efforts on creating a truly great product, because they must divide their attention on ensuring that they are not going to be stabbed in the back.  Even if the distrust does not rise to the levels where your resources begin to connive against one another, you still have a group that cannot truly communicate, because true, effective, healthy communication is based on a foundation of trust.

Dysfunction Two: The fear of conflict.

Great teams fight.  Perhaps the word ‘fight’ is a bit strong, but great teams are not afraid of conflict, because out of conflict can emerge true resolution.  I say true resolution, because resolution can happen without conflict, but it is not authentic because it typically is simply a result of one party giving in to avoid the conflict, rather than remaining passionate about the best outcome.  Conflict is not beneficial simply for conflict’s sake, but when teams fear confrontation and conflict, communication suffers, knowledge sharing suffers, and ultimately the individuals begin to manage their own actions from a place of fear, which never returns great results.

Dysfunction Three: The lack of commitment.

We use the word commitment a lot in Agile, but in this context, the word commitment is more aligned with being absolutely committed to the team’s goal rather than our own individual objectives.  When a team of individuals is committed to achieving the goals of the team, no other possibility exists, and when faced with adversity or the risk of missing an objective, the committed teams gets creative to resolve their own issues.  Commitment does not have a back door through which we can escape when times get tough.  When a team embraces their commitments, there is little that they cannot not accomplish.

Dysfunction Four: The avoidance of accountability.

The buck stops here.  Not at the desk of the project manager, but at the door of the team’s war room.  The team’s ability to remain accountable to their commitments means that creativity is likely to flow in the face of project difficulty.  I am not accidentally being vague here, I am purposely avoiding being too specific because I have seen many varied examples of how a team’s creativity in their attempts to resolve issues has surprised even them.  Keep all possibilities open, along with your mind, and allow the intelligent people you have assembled for your team to be accountable, even up until the very end.  With accountability comes the possibility of glory, don’t take this away from your team.

Dysfunction Five: The inattention to results.

In order for any team to have the possibility of making improvements, they must be able to honestly assess the effectiveness of their results.  It may be nice to sugar coat our reality, so that we don’t hurt anyone’s feelings, but all we are doing when we practice this soft-handed approach, is sweep under the rug the very information that is most likely to assist us in improving our future efforts.  Results are not good or bad, it is just information.  What teams do with this information will determine the character of the team.  Team’s that choose to ignore the difficult to digest results will continue to produce that same quality of results, but instead of improving their actions, they will simply develop an immunity to the effects the poor results use to inflict.  If it is painful for a team to honestly and authentically examine their results, then this is a sure sign that they need to examine them in detail.  Allow the team to feel the pain, experience any negative reaction that comes from this examination, and most importantly, use the total experience to open up the possibility of valuable conversations that will allow the team to avoid repeating it all again in the future.

There is no ‘I’ in Agile.

Individuals are great, I love having superstars on my team, but when we work together to achieve a common goal, I only recognize good team behavior, not individual efforts.  The people on your team are just like people everywhere, they are going to behave in ways which reflect how they are rewarded and recognized.  So if your company does not officially reward team’s that perform, only individuals (like during annual reviews), start the conversation to address this.  In you don’t, please do not be surprised when all of your cheerleading over the important of teamwork, team play, and team building are met with cheers, but then never realized.

Agile requires many different areas that reflect the need for a true cultural paradigm shift within most companies, teamwork and team building being one of the majors, so get ready, it is now up to you.  Becase if you have made it this far in my post, you have heard the bell.  And you cannot un-ring the bell, you know.

Here I was, I had a fresh degree from a reputable university with a major in Japanese, I had big plans to get  a law degree to practice international law, but instead, I found myself in the computer software field.  So how did my plans get so derailed? 

And what does this have to do with determining whether your Agile team should use a high-tech or low-tech tool?

Plenty.

You see, nearing the end of my junior year in college, my roommate kept himself busy writing something that was very new, pretty cutting edge, he was writing websites, USING MICROSOFT NOTEPAD.  He would show me a screen full of just text, then would click a button, and VOILA, there would be a beautiful website.  I could not understand how we was turning a document in Notepad into a picture laden website.  Now although I was impressed, I was even more impressed when he told me that he was making several thousand dollars a month creating and selling these websites to car dealerships in the Los Angeles area.  For the meager budgets of college students, this was more money that I had imagined making even after I graduated.

I was hooked.  I asked (begged is probably more like it) to let me in on this business.  He told me that we would be more than happy to have me as a partner, but I would need to learn the ropes, and that meant learning how to create my own web pages.  That was it, I was now on a mission.  I went home that summer and spent most of it reading books, teaching myself all there was to know about hand-coding websites, and then creating as many as I could, each better than the one created before it.  I was honestly pretty impressed with myself, and was looking forward to joining my roommate in our business adventure together.

The summer ended and I went back to school, excited to reunite with my former roommate so that we could take the LA area by storm with our websites.  I spent an entire afternoon showcasing the websites that I had created, painstakingly by hand.  He was impressed.  He spent more time studying the actual code than the marveling at my pretty websites.

After a good deal of time, he seemed satisfied.  He gave me praise for all of the websites I created and specifically for the fact that I had done them all by hand.   He could tell that I was anxious to begin discussing how we were going to proceed with our business, but before I could ask what our next steps were, he spoke first.

He said to me “these are great, you did really well coding these sites by hand.  Now that we are ready to develop some real websites, there is this tool we can use, it’s called Dreamweaver…”

Huh?  A tool?  Then he showed me the tool, showed me just how easy it was to create websites using this tool.  I found myself getting slightly angry, after all I had spent a great deal of my summer learning how to code these sites BY HAND!  I took a few deep breathes, and then calmly asked my friend “if there was this tool that makes creating these websites so easy, then why didn’t you tell me about this BEFORE I spent all summer learning how to do this by hand?  I could have created all of these sites in a weekend, rather than it taking me all summer.”

He smiled, knowing that my reaction would likely be just as it was, and replied wisely, “you had to.  You needed to know how to create these sites by hand, how the tool would be building the site behind the scenes, so that you could get into the code and fine-tune the website so that it is just as you want it to be.  If you ONLY knew the tool, but not the basics behind it, the tool would always limit you rather than support you.”

I am not sure just how my college roommate could be so wise at such a young age, but it is a lesson I will never forget.  And he was right too.  In fact, over the following few years I thought back many times to that first summer, and was thankful I had really, truly learned the trade rather than solely relied on a tool.  This valuable, unforgettable lesson applies perfectly to a situation I see teams new to agile get themselves into.  Their situation usually starts with a question like…

Our Team Is New to Agile:  Which Software Tool Should We Use to Manage Our Project?

None.  Instead, try Sharpies, notecards, a whiteboard.  You must learn the inner workings of agile first.  You must get good at agile.  You must develop the self-discipline that is the hallmark of good and great agile teams.  If you try to find a tool to use before you develop the basic skills necessary to implement an agile approach, then the tool will always limit you rather than support you.

The tools that are currently on the market are great, some even really great.  They provide a great deal of value and they have the features and functionality to truly serve the best needs of your agile team.  Some will save you time, others will save you money, some will do both, others will do none.  But for the team fairly new to agile, none of them will likely support your team’s best efforts in getting more proficient in agile.  This post is not about pushing one software vendor over another, but about the need for your team to build their agile skills before trying to use a tool that will ultimate limit their ability to grow their own unique brand of agile approach.

When you are ready, and you really are looking for some suggestions on the best agile software packages currently on the market, come back to my blog, because I am sure that by that time I will have finally posted my list of recommendations.  Until then, spend your summer getting good at agile.  I’ll be here when you get back.

A Belgian surrealist artist Rene Magritte used Korzybski’s notion in his work, and described the idea that was the foundation of his art as an understanding that “perception always intercedes between reality and ourselves.”  One of Magritte’s most famous works was an image of a pipe with a caption below it that read Ceci n’est pas une pipe (“This is not a pipe.”)  This piece was meant to illustrate that the painting of a pipe was not a pipe itself, but a representation of what his audience would associate with a real pipe.

So what does the phrase “the map is not the territory” mean for software development?

Plenty.  

Software development teams have a very difficult job. They must elicit requirements for a product that doesn’t exist.  In that effort, the customer then tries to describe this non-existent product, while the software development team imagines what the customer is describing.  In a waterfall approach, the first time that anyone finds out if what the development team built is what the customer wanted, needed, or asked for is during user acceptance testing.  This is very understandably why most waterfall projects do not end perfectly, or in most cases are far from perfect in their delivery.

Why does this so often happen?  Korzybski would describe this as being a suitable example of his concept that the map is not the territory.  Software developers spend a great deal of time in the requirements gathering phase attempting to construct a perfect map of the product territory.  But this map, this understanding of what the customer wants, generally results in the delivery of a product that misses the customer’s needs for the product.  It is not that the developers were not ernest enough in their requirements gathering efforts, it is not necessarily that the customer did not do their best to document their requirements, it is simply the nature of misses that occur when we try to translate what they customer is saying to what we are thinking, and then to what we ultimately end up building.  It would be like trying to construct a perfect map of the American coast based on the description provided by an explorer familiar with the area.  It just would not be a representation of any accuracy or quality.

So how do we proceed with software development knowing that this problem will continue to be a part of most software development projects?  Agile fundamentals recognize that in software development, the map is definitely not the territory.  So in light of this we only build small bits before going back to the customer to verify if our territory matches their mental map.  Showing working software is truly the only real way to ensure that what we are building is what they asked for, and more importantly, what they need and want.

The first step to avoiding the pitfalls of mismatches in understanding the requirements for a product is to open our eyes and check with our customer each step of the way.  We need to be aware that even with simple requirements, a simple product, or an impatient customer, there exists the likelihood that what we hear as developers is not going to perfectly match what the customer thinks they are saying.  

I use an exercise to demonstrate this phenomenon and recently had the opportunity to use it with a group of over 100 business analysts.  Each person participating in the exercise is given a single sheet of white paper, they are asked to hold it up in front of them, and then they are asked to close their eyes for the duration of the exercise.  Following everyone closing their eyes, I provide a series of very simple instructions (fold it in half, rip off a corner, etc.) while I am also following my own instructions.  They are playing the part of the software development team, while I play the part of the customer.  After a series of 4-5 instructions, or requirements, everyone opens their eyes, unfolds their paper, and then compares what they “built” to my requirements.  Out of 100 people participating in this exercise, would you like to guess how many folded their paper so that it matched my requirements?  If you would like to find out, I have the video of this exercise posted here (it is within the first few minutes of the presentation.)  Even with simple instructions, it can still be difficult to match the map to the territory.

A successful Agile team recognizes that their map will rarely match the customer’s territory without regularly opening their eyes and checking that their folds match the customer’s folds.