Who cares about your Agile development processes?

I find myself thinking that the software industry is far too focused on impressing itself instead of delivering solutions to people.  That somehow it's all about us.  It isn’t.  In recent years we have pasted the tipping point where the means, methods, processes, and techniques we use to build bigger, more challenging, more complex things is a more significant portion of what we do than producing products, improving our skills, and sharing experience with more junior developers combined.  The assumption that projects will fail is so rampant that it is nearly impossible to find a practitioner who will accept a gig without first declaring the process that will ensure success.   Unfortunately software development isn't about process or methodologies.  It’s not about change or risk management, documents, or estimation. It's about providing real value to real people. It's about outcomes. Not our outcomes.  Not how well, quickly, or even easily we created something.  It's about what we produce and how it helps the users that should matter most.

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.