First the punch line.  Go to Wikipedia and search for "Jumping the Shark". http://en.wikipedia.org/wiki/Jumping_the_shark   Here's an excerpt;

"Jumping the shark is a widely used idiom, first employed to describe a moment in the evolution of a television show, characterized by absurdity, when a particular show abandons its core premises and begins a decline in quality that is beyond recovery."

I am old enough to remember the television show referenced.  Happy days.  Specifically the episode where the Fonzie, a character that for the most part was endearing and, for kids of a certain age, epitomized cool and confident, with just a bit of the leather-jacket-wearing-don't-listen-to-your-parents rebel mixed in, was inexplicitly required to literally jump over a shark on water skis.  Indulge me in a bit of revisionist history as I prefer the often retold, but unfortunately inaccurate version that has Fonzie  jumping a shark tank on his motorcycle.  Keep this image in mind, we will be coming back to it.

Agile began as an uprising.  Individuals coming together to  ever so quietly rail against the way things were.  Some who are now nearly household names and others that were, and remain even today nearly nameless, focused raw emotion, real world tested skills, and a penchant for philosophy and patterns to create the Agile Manifesto and the supporting principles.   Without intentional marketing the ideas took on a life of their own.  Individuals became groups and soon whole communities.  The earliest Agile conferences brought likeminded agilest together to debate quality, technology, and philosophy.  The early gatherings  while serious in intent, never failed to loose site of a core tenant at that time.  Great software was a team sport.  Inclusive, open, and adaptable it seemed to be inherently fun to build, fun to use, and fun to talk about.  

Agile hadn't yet moved from early adopters to main stream.  Agile leaders and the growing number of followers were innovating.  Much like the early seasons of Happy Days, being different engaged an audience, being entertaining grew that audience at an impressive rate.  Somewhere around the fourth conference (and the fourth season of the TV show) things took off.  The number of attendees skyrocketed.  Agile was being discussed well beyond the original community.  If they had the funding they could have easily sold lunch boxes and action figures.  Happy Days did.

Not much after the 6th Agile conference you could begin to hear it.  The soft rumble of the motorcycle idling just out of sight.  The Agile community was splitting into camps and worse yet, being Agile became a way to make money.  For some, it was absolutely justified.  They had taken the freedoms, the open mindedness, and the focus on delivering high quality value to heart and were measurably better at delivering software. [Short aside; no one was really able to measure Agile in the real world until many years later when Scott Ambler was able to conduct well-formed surveys.]  Others were seemingly focused on making Agile bigger, branding, marketing, training , and certification were the new foci.  Knowing how to help others be Agile was becoming more important than actually being agile.  It was as if you could see the crew pulling the shark tank onto the conference floor.  The ramp was there and that idling engine was becoming a full throttle roar.

The conference was consistently beating prior year attendance records.  Agile books were top sellers.  New generations wanted to know how to be agile.  They needed to know how to be agile.  Software had become more complex and projects were, at least in the popular consciousness, failing at unprecedented rates.   Large system contract bid packages began requiring Agile teams as a condition of award.  Agile was booming.  Being process focused, having a methodology, made Agile look like a necessary and undeniably correct way to deal with the chaos.  No longer relegated to ideals of a few radicals it had become a full-fledged industry.  And just then, like the fictional character it was to become, our Agile motorcycle began a full throttle approach toward the shark tank.

The long slow fall from Fonz (cool and capable)  to Fozzy (the bear Muppet empty of real value but oh so entertaining in his own way) happened with little resistance.  The philosophy, the fun, the ideals of being agile (with a small a) was now an industry with rules, dues, and on-going attempts to define those who are Agile from those not deemed worthy of being Agile (with a capital A).  Barely a shadow of its former self Agile is now doing the unthinkable.  Agile is performing.  Agile has come to need an audience and Agile seems to believe that when it lands on the other side of that shark tank it will be met with applause.   And it might … others in the now very large, completely main stream Agile camp will applaud their hero.  What they won't get is respect, at least not mine. Not for that.

The originally conceived agile is still out there, doing good, helping people, delivering software.  Free from the prescriptive methodologies and in many ways providing value well beyond developers and the software industry.  These quiet champions continue without regard for the circus that the Agile brand has become.  They are smart enough to leverage the popularity of Agile without becoming distracted by the applause, the self-congratulating, and business driven industry parts.

Just like Happy Days after the Fonz jumped the shark, Agile still believes it's popular, even famous.  And like the television show it will undoubtedly continue on for many years trying to meet its own expectations  and recapture the greatness it had if only for a moment.  I do hope it will.  I will continue, in whatever small way I can, to do what I can to support agile .  If only to draw attention to the shark still in its tank, still swimming in small circles, ramp and motorcycle long gone, wondering what the noise was and whether its next meal will come suddenly from above or not.

Software is an ethereal manifestation built by people for people.  It's barely bound by the laws of nature and rarely if ever viewed by any 2 people the same way.  Even those who truly understand how it’s made rarely agree on how it should work.

Consider the simple requirement; “Add two numbers and return the result.”
Child's play right?  Computing power is clearly purpose built to do math.  So just what does it take, what do we need to understand to be good enough to call this one, very simple requirement, done? 

A little decomposition is in order.

Add.
A quick internet search on 'Add' returns nothing about math in the first dozen entries.  Both Bing and Google think a request to understand Attention deficit disorder is more likely than someone trying to understand this simple mathematical term.  Dictionary.com has 4 possible verb definitions and the first has two 'or' statements.  Seems the meaning of Add isn't so clear.  Darn ambiguous English.  Let's run with "to find the sum of" for now.

Two numbers.
Oh yes, another trap.  Is this any two numbers?  Can we allow 5 and VI to be summed to 11?  Will they be constrained to whole numbers? Will 4.967832 be okay or should it be rounded to 5?  What about 4 1/3 or Pi?  Convert to decimal and round first or after summing?    Is there any additional requirement to validate the two numbers individually, or as a pair?  Are these numbers abstract or maybe representing reference numbers of a known set?  Something like classic library reference numbers from the Dewey decimal system.  They went from 000 to 900 with 2 places of precision following the main classification.  So numbers above 999 would be inappropriate.

And.
Let's face it.  Good requirements shouldn't be compound statements.
Is this a condition of success?  Would correctly solving the mathematical expression without returning be another form of, or maybe a partial, success?

Return.
Although common parlance among technical types, return is no more precise than the rest of the requirement.  Return to where?  A function can return to its caller without ever leaving volatile memory.  Display is implied but where isn't clear. Should it be on screen or on paper via a printer?  Does it need to be placed somewhere specific on the screen such as a labeled field?  And does it need to be in a specific state, say available to the system clipboard?

The result.
Not to put too fine a point on it but 'the' certainly requires a singular thing effectively forbidding ranges, sets, and abstract numbers which don't result in a specific answer.   Unfortunately since simple math is only a small percentage of the complete set of math operations, we would be remiss to assume... right?  Even TRUE or FALSE could be as valid a return as any number.
Clearly even the simplest requirement needs deeper understanding and could be implemented in more than one, and only one way.  But let's make the leap. Let’s assume we know what it means to add two numbers and return the result. We still have a variety of unstated requirements to deal with;

How are the numbers provided?
What about errors and exceptions?
Do we maintain state between sessions?
Can a result be used as an input later?

What about the quality attributes?  Is it secure per session, per user, per role, or organization?  How about performance and scale?  Will this be done one addition at a time by a user or hundreds of times per minute by another block of code?  Is it limited to direct users input, if so, how many concurrent users does it need to support?

JUST WHEN IS IT GOOD ENOUGH?

Our customers and the industry suffer from this seemingly simple question. For some it’s never good enough. They dig and they plan, and test, and retry, never quite finishing … and never releasing a product. To others it’s always good enough. Work is released constantly, sometimes great, sometimes good, and occasionally useless. It’s left up to the consumer to decide if they should use it.

There are some, the professionals, who strive for and more often than not achieve a balance. They hold back when necessary, dig for details as required and release valuable, useful, usable products knowing they aren’t perfect. For me, it’s not just engineering. Software development is engineering, art, craftsmanship, diplomacy, and philosophy. The result may be quantifiable, but, like ‘good enough’ the process isn’t.

We, the practicing developers of the world, have managed to share so much of how we provide value that we have actually convinced those around us that the skills we leverage to do so are so important that they too should fixate on the process not the product. We did this. We can undo it. We can undo it while keeping an eye on the quality and repeatability of the process.  Process is, after all, only part of what we do; it’s just one tool, something we use not something we deliver.  It’s certainly of no value in and of itself.  No one should get paid solely to ensure process quality.  Instead we should only get paid when quality is an undeniable part of our solutions to our customers problems.

We have to set our egos aside and ask each other, if not ourselves, why do customers want to know or even care how we do things.  For me, it’s simple.  They are tired of being lied to.  After years of unfulfilled promises and undelivered products ... hold on to your hat... they don't trust us.  Hard to believe I know.  After all, we are the ones who understand and control the machines they so desperately need to do their bidding.  We, the few, have been empowered (or at least employed) to stand as judge and jury over the efficiencies of our customers business and choose for them what magic the machines should produce. 

As things stand, many if not most of our customers need to seek any evidence they can proving that all of the work reportedly happening and all of the money they are spending is actually getting them closer to what they believe they are supposed to receive.  They want, and righteously deserve, to know not just believe.  They need assurances they can use to justify the expenses not just endless invoices for hours leading to some promise of future delivery.  They need milestones, quality gates, reviews, weekly meetings, and status reports.  They want to hold us accountable and in response we offer them transparency.  Let me be clear here, transparency isn't accountability.

My good friend Scott Ambler has taken to discussing the integrity debt of the industry.  I think he is really on to something.  This is the debt that accumulates when we do stupid things like charge our customers to learn about us and how we do things (Bing "Certified scrum product owner".  That’s right we are going to charge our customers to be better… uh ... customers ). Integrity has become as scarce a commodity as truly successful projects.  It's out there and when you do come across it, you are likely to be facing mountains of it.  Integrity attracts integrity.  Nonetheless, its absence is nothing less than a cancer in the industry, eroding trust, driving more meetings, more milestones, and paying for new cars and college funds for attorneys everywhere.  Without integrity and trust we can never truly elevate our industry to a true profession. 

In the most recent batch of prescriptive methodologies flying the "Agile" banner as if it were theirs and theirs alone, there seems to be a compulsion to treat everyone remotely related to a project as peers, equally responsible for success or failure.  Self organizing, self managing, self evaluating, self-testing ... just plain selfish.  The mob, justified by group think and zealously sure that doing things "their way" will ensure success, takes every opportunity to communicate.  As valuable as communication is to any team it's far from a universal suave healing wounds left by information overflow, analysis driven paralysis, loss of focus, and many, many other ailments that haunt any team working on complex tasks.  Like transparency, high levels of communication are a good even necessary component but far from a dominate force for success.

I'm not calling for a full fledge revolt on process and process improvement.  Just tone it down. Great process will not guarantee delivery nor will poor processes doom a similar attempt.  Process is merely part of a larger whole.  It’s true, we need to be better and yes, process, rigor, and repeatability are some very important tools in our toolbox.  I know people entering the profession want to believe there is a way that works.  They want to learn from those who came before them and understand how they too can best serve their customers.  Ah, who am I kidding; like anyone new to a job they want to be productive now without the pesky burden of experience. 

I propose that process transparency is more akin to an effective sewage system than a crowning achievement.  It sure was an important advancement in its day and it has clearly improved the lives of many.  After all this time, users should be able to assume it’s there, and it has an inherent capacity to serve all who need it.  No pomp, no circumstance, no lengthy discussions on it value or impact.  And much like a sewer system, no one really cares about how it works.

That's the moment of truth.  The moment when customer expectations are set.  When we tell them, with as much sincerity as we can muster, that they are not only a part of the team but the sole owner of the definition of success. 

Read that last sentence again ... go ahead, I'll wait right here.

Do you see it?  The hypocrisy  the abdication of authority to the customer.  The slimily, irresponsible, verbal sleight of hand that forces the burden of success onto the shoulders of the very person who has come to you for help.  If that isn't evil incarnate I don't know what is.  Don't get me wrong, I'm right there with you.  I've done it.  Worse yet, I've done it knowingly.  After all that’s the business we’re in. Customers want something and we want them to pay us to build it, or at least try to build it. 

We are unique, but not in a good way.   Unlike the power classes that have come before we have had authority handed to us without the burden of contributing back to the system we have been so boldly authorized to defile.  Contrast that with the titans of the age of enlightenment who did prosper on the backs of others but they did so while also providing socially beneficial innovations.  Innovations in the form of new types of government, education for all, and my personal favorite, plumbing.  Sure they were shunned as oppressive but in broad strokes they improved things.  Even the power barons of the industrial age brought innovation to the masses.  They built real, tangible things. OK, so they endangered workers with factory conditions that made smoking look downright good for you.   More important, they used their own money (well, their families’ money) to control markets, exploit workers, and manipulate society.  The consumers of their goods paid for things that were, by the manufacturers’ standards, complete and useable.  This actually gave the barons of industry the moral high ground over the lowest form of capitalist in their day, the stock brokers.  The brokers were peddlers of the wares produced by others.  They taxed the transaction with little value added, essentially making money from money without material contribution.

That was then.  Let’s get back to now, back to us.  We, the titans of the information age don't produce anything tangible.  We don't even come up with the good ideas:  our customers do that. Yet we dare to demand payment for our willingness to try to build what they envision.  We make promises of delivery that are statistically* not worth the air consumed to express them.  Even our contracts fail the basic premise of a contract in every other industry.  Elsewhere, in modern and older times, contracts provide a durable, binding way to ensure all parties knowingly and, on occasion, equally share risks and legal protections.  We don't have building standards.  No association ensures we are self-policing.  No law requires our failures injure us as they do our customers.  Did I mention evil?

I know what you're thinking.  I can hear your voice in my head as I write this.  "It's not our fault!  How can we possibly be held responsible when the customer is unclear in their wants, needs, and desires?"  Right you are.  What are we, mind readers?

This is where I have to reintroduce our hero and villain, that favorite of all software development fall guys, the requirements.  Requirements have, for most of software developments history, been our best defense against the endless ambiguity we suffer at the hands of our customers.   After all, requirements make those contracts work. Oh how I love them.

In the hands of a master software developer requirements are both carrot and stick.  They provide a means to entice the customer to participate.  They can deeply affect the timing and value of the solution delivered.  When seen as opportunities, not obstacles, requirements cradle a project in the warm embrace of constraints.  They define boundaries within which the solution lays and beyond which no developer should trespass.  They set the bar (achievable or not) that the team can focus on and on good days exceed. 

Of course master software developers are few and far between.  And to be fair so are really irresponsible, malicious, incompetent software developers.  The world as we know it is, by its very definition, filled with average software developers.  If you want to get really picky it’s the 75% middle portion of the bell curve, not the mathematical average but let's not drift too far off topic.  The more important point is that we are focused on the bulk of the population of all software developers who do the bulk of the work.

Here's where it starts to get tricky.

I'm going to define an average developer as having three to five years of real experience.  You know, paid work with customers they aren't related to, or somehow close to anyone they meet in college.  During those three to five years it is likely that our average developer has only worked on one or two projects requiring more than four or five people including themselves.  They have been on only one or two projects from the very beginning and even then are statistically* not likely to have stayed engaged from inception to delivery.

Consider the now infamous chaos report.  Over the last 10 years the industry has never done better than 35% of projects started actually ending in success.  If you are willing to accept that as true, and you should ... I read it on the internet... then it is not too much of a leap to believe 65% (or more) of the industry has NEVER delivered successfully.  They have never tasted the blood in the water that is success.  What form of insanity is it that we believe this average software developer could ever deliver on time, in budget, and within scope? 

And what about all those project leads, technical leads, project managers, program managers, high end consultants and coaches (some of which spent as much as two full days achieving the vaulted Master credential), that bring their vast experience to bear guiding and molding our average software developers into better, more capable members of our little IT society?  What do they bring to the table to better ensure success?  Let’s count the ways shall we?

First among all credentials is proof of experience, and yes, by proof of experience I mean resume.  It is the rarest of seasoned IT professional that doesn't have 15 to 20 years of experience proudly displayed in chronological order.  They have been working with computers since that first fateful college course where they spilled "that" box of punch cards and spent most of the night sleeping on the couch in the computer lab eating pizza and waiting to hear that their punch card program did or did not run.  They have worked with a dozen big name companies leaving one very important project (before it delivered) to take on a more complex, more challenging project with an even bigger name company.

Impressive, yes.  Comprehensive, you bet.  And look at that font! 

The trouble isn't what they have done but what they can do.  Are you working with punch cards?  I'd be willing to bet a Euro you aren't.  Do the leading edge technologies they helped create years ago still lead anything?  Probably not.  Last, what happens when you ask what I believe to be the most important question of all; what did they materially contribute to their most recent success?  Not what their team did, but what exactly did they do, with their own hands, under their own power.  What problem did they correctly predict, and ultimately prevent or solve?

In a recent round of candidate interviews I couldn't help but replay a scene from that seminal movie of the 20th century, Office Space.  When asked by the Bobs to describe his job our proto-typical middle manager proclaimed that he "... was a people person damn it!" [He] takes the requirements from the customer and gives them to the engineers."  It is an all too common, and in my opinion, sad end to many otherwise brilliant technical careers when the decision is made to promote them into management.  Expecting their hands-on delivery skills to magically transform into leadership and organizational skills is little more than a folly worthy of a Shakespearian tragedy.

If we don't have a vast army of experienced leaders who can guide our average developers to success, what else could we possibly provide them to improve their chances of actually delivering value to users?    Every culture since the dawn of time has been defined by how lessons learned are passed from generation to generation.   Being good at passing learning forward to enables subsequent generations to not only avoid the mistakes of their predecessors but to exceed their greatest achievements with even greater, uh, achievements is an indication of maturity our industry has yet to achieve.

Unfortunately software developers have more in common with the Neanderthal than modern man.  While modern man has a lifespan creeping up on 100 years, allowing multiple generations to overlap, our current software developers struggle with generations as short as a few years and technology shifts likely counted in months. 

The ever increasing speed of technical change has only amplified our problems.  Lessons learned during one generation simply don't apply to the next. Memory management in the 80's isn't relevant to any but the rarest few who build the runtime compilers the rest of use to handle those low level tasks.  Even those lessons that do apply are largely left to oral historians to pass through mentor / mentee relationships.  I know that sounds ridiculous but as a group we have failed to create highly available, searchable repositories where less experienced software developers can find relevant information that would allowed them to avoid the mistakes of the past.   The web while arguably comprehensive and searchable is a bit too volatile and fails to provide vetted, definitive information.  When faced with a new challenge our average developer will likely take one of the top few returns from a search and try to blindly apply it to the problem at hand.

Our skills may be atrophying with each rapidly passing generation but that's nothing compared to the speed of change in user expectations.  Long gone are the days when users were impressed by two documents side-by-side on the screen.  Not only do they expect every solution to use the very latest (frequently untested if not unstable) technology but they want to be involved in the less technical portions of a solutions’ creation.  They demand to dictate the colors, the layout, the features, the workflow, and more.  After all who better to decide how to elegantly layout a user interface than the business subject matter expert who struggles with document page numbers and printing labels?

That brings us full circle to requirements.  Once we agreed that a customer could have their way with a solutions’ design we needed to capture their ideas, both good and oh-my-god randomly insane.  Way back in the 70s and 80s this wasn't as much of a problem.  Technology was simpler and the wants of our customers were easy to describe in plain text.  Those simpler days are long, long gone but we continue to both define requirements in plain text and allow users to drive the design of solutions.

You see, it’s not a failure of requirements management; it’s a failure of the requirements that haunt us.  Contractual language is not expressive enough to capture what a system should / shall / must do.  Current efforts to describe solution parts like user experience, navigation, workflow, business rules, component design, system constraints, system goals, as well as the limitless negative things a solution should not do, more closely resemble iambic pentameter than software design goals.  Similarly the technical skills of past generations simply did not include the necessary soft skills that separate success from failure on today’s complex solutions.  Customer management, team dynamics, interface design, and multi-disciplinary tasking are but a few skills that didn't even exist in the software development world until recently except for the truly rarified air that built multi-million dollar, sophisticated, large, complex and mission critical systems.

The answer lies, as I mentioned at the beginning of this rant, with each of us.  Not only must we let go of the comfortable ways that have served us for so many years but we need to do what for many is simply unthinkable.  We need to work together. We need teams of skills that are applied as part of a thoughtful and well-choreographed improvisational theater.  We need to accept user input as rough cut story boards from which clear decisions will be refined.  User input is not a legal or moral mandate handed down from on high. User requirements are just one of the many variables that will go into the stew that is a modern software solution.   After all, this is far more art than science. 

Our job is to deliver a high quality solution to the users.  This is far more likely to be successful if the entire effort is an ongoing collaboration with the very same users.  Just doing our job hasn't been, and continues not to be, enough.  I believe it’s our mission to build upon the successes of the past, to leverage the lessons learned, and, with each and every solution delivered, improve our industries ability to take user requirements and turn them into more than they had hoped for.  

The sooner we;
*  convince ourselves and our customers that the definition of success includes, but is not fully defined by, early stage requirements,
*  accept our role in managing expectations and driving non-user requirements and constraints into the definition of a complete, high quality solution
* see getting paid on acceptance of a high quality delivery as the norm and shun those who accept payment for merely trying, the sooner we will achieve reasonable, consistent, and equal relationships with our customers.

As soon as we look to ourselves, our team, and our customers as the source of success instead of failure, then we will be free from the evil that requirements have become.  In short, although I suspect I past short many paragraphs back, we need to participate.  Much like any other part of the software development process, requirements need to be managed.  I'm not talking about the formal requirements management process.  I'm talking about acting with, for, and against them intentionally.

This should be the kind of problem software developers enjoy.  It's a multi-dimensional puzzle with both slowly changing dimensions and temporal components.  Requirements exist on multiple planes immune to simple-minded linear thinking.  Requirements don't have a lifecycle.  They are simultaneously known and unknown, both immutable facts and infinitely malleable concepts.   

We routinely refer to requirements as high level or detailed, as core, original, technical, system, or functional but we fail to evaluate these and many other labels over time.  Somehow requirements have become some kind of  guide rail protecting our nearly out of control car from careening off the well-known road to success and exploding into the horrific but certain-to-have-killed-all-occupants ball of fire used in every cliché car chase Hollywood has ever produced.  Just like the movies, it’s an illusion if not more correctly branded as a delusion. 

Guard rails won't prevent a truly out of control car from leaving the road and cars don't burst into flame on impact.  Similarly requirements aren't going to keep your project in check and you won't fail if you move, change, or even disregard them.  Safety comes from skillfully negotiating the turns in real time.  It comes from looking ahead, sometimes far ahead, identifying threats both potential and real, and changing course.

That's the secret.  Pay attention, make choices, and act on those choices.

If you want to succeed in software development, if you want to deliver value to real users, if you ever hope to mature from the current generation repeating the mistakes or prior generations, if you are to set aside the hubris that you are somehow in control and managing the chaos that is the creation of a software solution, you need to stop treating the needs of your customers as static.  Whatever form requirements may take they are merely snapshots of the shadows cast by fleeting ideas.  Good clues but hardly stable, contractual definitions of success.

This is particularly onerous on large projects spanning more than 6 or 12 months.  Everyone learns, things are discovered, staff comes and goes, and priorities change every day from the very first.  What kind of crazy is it to believe that this one aspect of the project is somehow immune?  Software, really great software, while a reflection of the developers who create it, is an extension of the people that use it.  People, not a person.  People with a broad spectrum of wants and needs.  People who are affected by time and politics.  Great software gets to version 2.  The users will never stop wanting change.

While every solution must be technically correct, performant, and stable, it is equally important that it be inventive, capable, engaging, and even fun.  I have never seen a requirement for fun but I know solutions that are enjoyable to use seize market share and live for a long, long time. 

We need to step into the light, banish the evil, and act like the mature professionals we claim to be.  Through the continuous re-evaluation of the definition of 'done' we will be able to increase the likelihood of successfully helping our customers.  As software developers it is our ability to listen to our customers throughout the process not just during some artificially time boxed requirements gathering phase and tell them the truth about their wants, needs, hopes, and desires, with all the complexities, and painful realities that transform our customers from being part of the problem to being part of the solution.  Unlike those who hire us to turn dream into virtual reality we need to be proactive and deeply, personally responsible.

*any similarity to real statistical analysis living or dead is entirely unintentional.  These are completely unfounded statements.

10- Politics

Creating software is like being an elected official. You get into it to do something, achieve something, and participate in something larger than yourself. You are "forced" to take on non-productive tasks like fund raising and campaigning. Eventually you stop fighting it and set aside a (growing) percentage of your otherwise productive time. Accomplishment slowly moves from what you can do to what you can get others to do and success is measured through polling and statistics. Instead of counting delivered projects, you know what percentage of projects succeed; in place of consistently delighted customers you trend against customer satisfaction scores.

9- Music

Great software is like great music, you might not know it when you first encounter it but compared to some number of others it feels better. It’s a bit more popularity contest then technical superiority that makes great software great. The more people talk about it, the more they promote it, the more "air-play" it gets, the better it becomes. The music industry tracks number of spins and downloads. The software industry talks about de facto standards and broad usage. Neither speaks to the actually quality in any measurable way. Even underperforming is similar in both products. Really bad music, like its software counterpart, just doesn’t get a chance. It is generally identified by a select few and prevented or withheld from the intended audience.

8- The law

Good software, like a good law, is the result of collaborative debate but rarely complete consensus. Great laws, like great software require time ... lots of time... in the real world. They need to be poked and challenged by those impacted by them. They need to be enforced to ensure a large population complies while at the same time requiring a set of experts to judge them in context, interpreting original intent against actual performance. Both may be modified to account for unforeseen circumstance but neither, once broadly accepted, can be readily discarded by the system that created them nor the population they effect.

7- Battlefield management

While I don't mean to in any way belittle the heroic efforts and significant risk to those in real battlefield situations; software, particularly large complex solutions, required a level of persistent focus and simultaneous strategic thinking comparable to battlefield management. Leadership, good or bad, radically impacts the outcomes. At any moment in time there are hostile activities encroaching, counter insurgency tasks in various states of completeness, supporting logistical efforts in flight, and long range strategic planning efforts undergoing review and change. All of which require error free, clear and decisive decisions. The ongoing dance throughout the team hierarchy (and even the most agile processes have a hierarchy) relies on clear communication and a willingness to do tasks without too much regard for the "bigger" picture. Success is clear in the small and much less so at the macro levels. In both software and battle, victory is as much a state of declaration as it is fact. A solution is baselined be decree, and you may or may not move immediately to the next skirmish / release.

6- Mobs and animal packs

Take a number of people; give them a singular, albeit ambiguous goal. Allow them to self-organize both as they relate to each other and how they address the work at hand. Accept the fact that bad things will happen and progress will not always be in the "right direction”. Congratulations, you have a mob ... or a software development team ... what's in a name anyway. Even the biggest most organized software shops have internal cliques, undeclared leaders, and sheepish followers. It is natural to seek safety in the herd and even more natural to blindly follow when "everyone" seems to be turning in a particular direction. Oddly, this is more a benefit than an issue for the development community. If too many individuals work too independently the solutions are never built, predators eat the heard one-by-one, or the herd simply abandons the individual instead seeking a consistent group dynamic over the pending chaos. Software, built by the collective, is successful of the collective survives to bill another day.

5- Medical diagnostics

When you have a problem you go see a doctor. When our customers have a problem they turn to software. Oh sure, there are times when things are going well and an organization takes preventative measures. It might be improved exercise and diet or the software equivalent of continuous improvement and rigorous process. It might be a simple yearly check-up where they review well-known and meaningful measures from the last period against the current state or identify metrics that don't seem right and require additional action. Unfortunately these preventative good habits are truly rare in the IT world. Instead the most common case is to deal with a traumatic injury. To reactively mobilize, triage the issues, occasionally diagnose the underlying cause, and devise a treatment which will at least relieve the symptoms. Some customers are delighted to "feel better", some demand a real cure and other are simply hypochondriacs, never satisfied, always fearful, and would rather see activity and never actually concern themselves with progress.

4- Diplomacy

Whether it is your first time in a new culture or your first foray into a new business vertical, software professionals need the skills of a diplomat. They need proficiency with multiple languages, and enough empathy to intuit what isn't stated but is still required for understanding. If a stranger from a strange land who doesn't speak a language you recognizes sits across from you, lifts a cup of liquid from the table and says "flubber", what do you suppose they are telling you? "Flubber" is cup? Or is it liquid or are they toasting to you? Creating a software solution that adequately addresses the needs of real people requires soft skills before hard skills. Much like a diplomat, IT professionals need to gently interrogate customers, users, stakeholders, team members, and peers. Listening and questioning trump pure knowledge every day. Generally imposing ones assumed knowledge too early in the process creates haunting errors un-resolvable later on. What one might know to be true is irrelevant in the face of learning and understanding what those around you believe to be true.

3- Team sports

Building software has more in common with team sports than simply requiring a well-functioning team to succeed. Unlike brick and mortar construction which has a large number of well-known examples against which complete can be judged, both software and team sports play until they are out of time. They strive to achieve throughout the available time period but the time box rules the overall process. How much you achieve, be it points or requirements, touchdowns or iterations, goals or scenarios, is fluid. More often than not success is doing just a little bit better than the customer expected. Delivery alone is good, but beating the point spread makes everyone that much happier.

2- Driving in dense traffic

Building software is like driving in dense traffic. You control your immediate surroundings and there are clear boundaries between what you can affect and what should affect you. You look ahead and change lanes based on the conditions of the moment only to have those conditions change immediately afterwards. Others nearby have goals of their own. They too are empowered with little thought of you or concern for your choices. You’re as much a part of their changing environment as they are of yours. No car in the flow can make a choice in isolation. Just like the evolving subsystems within an enterprise. Each seems discrete. Planning, based on known current and best guesses of the future, is important, even useful, but must continuously adapt. Changes made to any one will, intentionally or through unpredicted side effect, impact all others.

And my number one replacement for building architecture as a metaphor for software development is;

1- Sailing

Leading a development team is much like captaining a ship. You know where you began, you were there. You know where you are for the same reason. You know where you want to end up and you have a plan to get there. You lean on your experience and the skills of your team. You apply the best tools available. Even so, the weather, the tides, and the general randomness of the universe will find a way to challenge you. Simply following the coast line requires continuous observation. Every detail of every part matters, and every part doesn't work perfectly. The plan on paper is nearly a straight line, but the real world finds even the smallest variation from perfect and creates unforeseen challenges. When things are going well you must look for the problems you might have missed. You need to perceive the unseen rocks below the waterline. Usually, things aren't going to go well. You adapt, adjusting course, conceding time, but never forgetting the destination. Anything less would leave you and your crew simply lost at sea.

· The system shall properly calculate the taxes due at the time of payment.

· The system shall properly display the location and speed of inbound projectiles.

· All users will only be able to change data appropriate to their role.

They are a clear example of poor communication and are likely to lead to more poorly managed customer expectations. I doubt any requirements analyst worth their salt would consider any of these adequate. They are at best ambiguous and there is little doubt that ambiguous requirements are frequent contributors to troubled projects.

That being the case, just what is it that would make these and other ambiguous requirements better? What would make then more achievable? More importantly, what would allow us to deliver well and in such a way as to meet the needs of our customers? While I would love to propose that all requirements include their definition of a successful outcomes and the metric that defines success I am more concerned about the current trend toward wielding requirements as a weapon instead of using them as a tool to further success.

All requirements, functional, technical, user, documentation, security, performance, etc... can be measured. It's just hard. It's the kind of hard that seems to get sweep aside because it takes too much time at a time when everyone wants to just get to work. It requires non-development skills like interviewing, analysis, and negotiation. It forces teams with short timelines, little budget, and high expectations of achievement to focus on the business of the users, something they have little control over, and not themselves.

On the one extreme, failing to properly define the requirements has been pushed aside by the new generation of agile practitioners as too much upfront work or a fool’s errand. On the other extreme is the formal community who may defer development until all the "knowns are known" but have yet to engineer a litmus test for requirements quality. In the middle is a form of compromise. Requirements are not the goal. I have never seen a successful project that simply met all of its requirements. No, requirements don't define a project, they are just are one of many ways the team ... all roles including the customer ... creates tasks, discusses priorities and trade-offs, and works through the unavoidable complexity of discovery throughout the software development life cycle.

If instead of placing requirements between the team and the customer each demanding the other becomes more and more specific. You can use the activity of improving the quality of the requirements as part of the necessary and on-going communications within the team. Requirements like models are built to improve understanding. They are communication tools and much like other forms of communication when the quality if high everyone wins.

Fear in a troubled project is both motivator and obstacle.  It is not uncommon for fear to be used as a weapon against the team and the customer.  Most leaders who extort others are generally unaware of the effect they are having.  They mean well, yet their actions and words come off as just mean.  The customer begins to fear complete failure and its effect on their own careers and credibility.  The team usually responds by fracturing into tribes, shunting communication, redirecting blame, and generally assuming delivery isn't possible, instead spending their time on survival.

Uncertainty is more insidious.  Unclear goals, a staple of modern system development, mix with unclear direction to create a cloud of ambiguity.  So called hard deadlines are missed without repercussion while unstated, seemingly unimportant, low level details set off a fire storm of retribution.  The rules, if there ever were any, are tossed aside for a kind of anarchy.  Anyone could be in charge, and anyone could derail the team.  Uncertainty takes the fun out of everything.  Mondays are met with dread.  Meetings are missed.   Schedules slip.  And all the while no one knows why.

While fear and uncertainty are evil in many ways, Doubt is by far the most dangerous.  Doubt requires a mere statement from a trusted source made with conviction and certainty to heard by someone who accepts it at face value.  A senior team member might be overheard saying; "There's no way this is going to work." in a break room by a more junior person.  It doesn't matter that the statement was about microwaving jelly beans.  The credibility of the source makes the statement true.  Although born out of context it is more likely than not be repeated ... spreading doubt.  Worse yet, the unwitting leadership is suddenly faced with a team that thinks the recently agreed upon statements of success were lies, and the leaders may never know why the teams attitude began its downward spiral.

Recovery is as much about the human factors as the technical ones.  Of course you have to be good at the technology.  You must be able to leverage your experience delivering successfully in the past and you must have a broad array of process and practices to apply throughout the lifecycle of the project.  It's just not enough unless you can apply all of those things in such a way as to reduce if not eliminate fear, remove uncertainty, and help those who doubt see the inevitability of success.

In this era of fast small deliverables,  short timelines, and rapidly changing goals it's easy to forget it's just software.  As an industry we are facing decreased demand due to macro-economic pressures, and increasing expectations as our users first become accustomed to, then jaded by, the latest eye candy and features all of which tend to drive us to work as though our lives depended on working.  Today’s reality is quite the contrary.  Our lives may depend on our not working.

We are nearing epidemic H1N1 virus levels.  Entire organizations will close as the percentage of sick employees climbs upward.  So whether you are home with a sick child or just feeling ill yourself, do everyone a favor.  Stay home and just keep telling yourself ... It's just software.

• Modeling to communicate,
• Modeling to understand, and
• Modeling for reference.

In reverse order, Modeling for reference is the traditional goal.  It is intended to read by someone (usually at some future point in time) new to, or somehow removed from the original development effort.  The model needs to neither mislead nor have important gaps and must comply with the standards for that model type.  After all the standards allow a reader to understand the model without the original context.

Modeling to understand is a more requirements gathering effort.  The creator is the likely consumer and it is intended to be an aid, not a deliverable.  Simple and well understood things need not be included instead the models tend toward fragments being analyzed instead of depictions of the whole.  Think of them as quickly taken notes and relevant doodles done in your own handwriting using symbols likely to be meaningful only to yourself.  As such models for understanding can be, but are not required to be good historical notes about how or why a decision was made.  They are not intended to be good tools for later reference.

Last, modeling to communicate is done to share ideas or restate an understanding for validation.  They are semi-structured whiteboard-like drawings which, once done communicating their point go quickly out-of-date.  They tend to use symbols understood by the parties involved which may vary wildly from the official standards of the model type.  It is far less important to be right than to be understood.  However, should the model persist too long, or should someone from outside of the original discussion get their hands on it, clarity becomes the first causality.

In practice this means the actual value of a best practice isn’t the advertised return but a possible return from within a range of returns. If we take the example from my last post; adding a new tool to address testing quality and velocity.   It is easy to see that when a practice is done well it can provide significant improvement in overall product quality.  On a reward scale of 1 to 10, I’ll call that an 8.  When it is done poorly, it could increases cost or inject delays into the schedule.  On the risk scale, this time from -1 to –10, I put that at –6.   Now we have a range of potential that is 14 points wide going from negative 6 to positive 8. The actual value is highly dependent on the specific implementation within the context of the team and the mixed effect the combination of practices being put in place.

Before we get into the weeds around how we can use these values I want to propose a simple, consistent way to describe the points along the range.

If any of you know me, you know I'm not actually a fan of standards.  In fact I have been known to violently oppose the idea of compliance where integration will do.   I will however concede to the point that nearly every attempt at integration requires agreed upon terms if for no other reason than to limit semantic arguments.  Here then, is my proposal for a complete Risk / Reward scale for evaluating practices;

RISKS
----------------------------------
0 no impact
-1 negligible impact, easily resolved
-2 likely to create additional tasks
-3 scope of issue expands
-4 degrades team morale / communication
-5 requires notable response
-6 increases cost or delays schedule
-7 injects current and future issues
-8 degrades solution quality
-9 critical feature failure
-10 prevents delivery

REWARD
----------------------------------
0 no impact
1 improve poor performance to nominal
2 reduces isolated level of effort
3 broadly improves things
4 improves team morale / communication
5 measurable improvement
6 reduces cost or schedule
7 resolves current and future issues
8 significant improvement in overall quality
9 ensures feature delivery
10 ensures total delivery

In the next post I'll show how we can group practices and by using this scale remove much (but not all) of the guess work from selecting, and monitoring, corrective practices.