From "Agile" to "Astute:" Value Wrangling Requires Technique

I've been putting my shoulder to a wheel which Jim Highsmith has steadily pushed for a long time, and which Gojko Adzic has started actively evangelizing over the past year or so, which is a group effort to brand, rationalize, and advertise practices to help teams "build the right thing" as a complement to the fairly well established "agile" practices for helping those teams "build things right."

Like the Agile Manifesto drafters, who came together in 2001 as established and successful software delivery practitioners, Adzic has brought together some wonderfully talented practitioners into his discussion space, many of whom have already published substantively on the topic.  To name just a few:

• Adzic himself with his 2013 book, Impact Mapping: Making a big impact with software products and projects, building on his previous explications of specification by example.
• Ellen Gottesdeiner and Mary Gorman with their 2013 book, Discover to Deliver:  Agile Product Planning and Analysis, along with a decade's worth of helpful publications on value-focused product delivery.
• Kent McDonald, blogger at Beyond Requirements and author of Stand Back and Deliver:  Accelerating Business Agility.
• Jeff Patton, blogger at comakers and father of one of the best-known agile analysis tools in use around the globe, Story Mapping.
  

Additional contributors to the effort include Scott Selhorst and Adriana Beal, who have recently posted some great observations to their respective blogs about avoiding "cargo cult" requirements.

But there is a problem.  As the original Agile Manifesto framers did in 2001, Adzic is facing a tricky task this year in coming up with the right name for his endeavor, or even to get something of a grip on what the goal is.  Code names used so far by Adzic include: "February Revolution," "ThisCon", and "Astute." 

An Astute class submarine, from http://www.military-today.com/navy/astute_class.htm

I was excited to find out that "Astute," the last of these three, is not only a clever and alliterative companion-concept-name for "Agile," but also a class of nuclear submarine.  Despite, or perhaps because of, its ominous echoes of instrumentation for mass destruction, "Astute-as-submarine" provides a nice metaphor for practices needed to find out what a project sponsor actually wants on an ongoing basis, and how to provide her with an evolving product which is always a good fit.

There are (at least) three problems a value-wrangler needs to solve using a whole arsenal of tools:  1)  motivations behind product investments are never visible on the surface, 2)  the decision maker is going to keep changing the exact coordinates of the destination, in terms of the specific features which will best express her motivations, and therefore 3) if a professional value wrangler is doing her job well, she will be invisible except at deployment, and maybe at that point, you don't see her either.

Unaddressed, these three problems leave teams team constantly looking for new landmarks, and, worse, they fail to recognize team members who are vital to their continued success.  "Astute" philosophy and practices address these problems.

1)  Why Are You Building It?  Don't Trust Surface Appearances.
You may be tossing your head and saying "just calculate the per-feature NPV and go!  How hard can this be?"  Indeed, the "Net Present Value" of an investment, looking at initial investment, income stream, ongoing maintenance costs, all adjusted for inflation, if calculated uniformly over a set of investment possibilities, could lead to an orderly portfolio process.  Entire books assert it!

But anyone who has ever provided advice to an executive knows that the numbers are simply a proxy for the power structure of the organization.  The project will be executed or not, based on whether the detractors are stronger or weaker than the proponents, regardless of what the numbers say.  To provide just two large-scale examples:

• Read this independent analysis on Chicago Mayor Rahm Emmanual's business case for closing 57 public schools this month, the largest mass school closing in the history of the USA.  The cogent fact is, he wanted to do it, he could do it, and he did it.
• Read this analysis from a Financial Times article about the business case for building next generation High Speed Rail in the UK (thanks to Ross Pettit for the tweet calling out this wording!)  One day there may be numbers, but they will come after the decision.

Organizations are about emotion, power, and influence.  The numbers will always support those actual drivers, or the numbers will somehow turn out not to be "Key Performance Indicators" in one way or another.  Do not be tricked into thinking that you can understand why a project is still funded, or why a project is getting started, based simply on a logical business case.

• Sometimes there's a burning platform .  Ockham's razor says that at least some of the time, all you need to do is some sanity checks with key players to confirm their real motivation.  It could actually be true for this project that there's some "pain point" or some huge opportunity that the company should logically pursue, and your decision maker is making sure that the company does so in a cost effective way.
• Sometimes the real motivation is completely different.  If the CFO is asking you to fix the problem with "waiting room utilization" in the company's fleet of podiatrist offices, she could be asking you to create a more welcoming atmosphere to drive sales, or to grab some of the space for a bigger display of shoe polish, or she could be creating a cover story in order to get the company facilities architect fired, because she's mad about love gone wrong.  You don't know. 

You need to know.  Your project's success rests entirely on getting aligned appropriately to the actual motivations as well as the sanitized ones used for public consumption.  That is a tricky business, requiring work at multiple levels and repeated adjustments to avoid getting the bends.

2)  What Are You Building?  Don't Get Too Attached To Your Original Landmarks.
For a typical product, the visible landmarks representing "product value" are a choice of:

• A "fixed scope" with specific features and components laid out in detail and analyzed by the product people for potential ROI or
• A determination to avoid "fixed scope" in favor of creating a permanent team which can react quickly to breaking market conditions by waiting to split and estimate stories from epics until "just in time" at a rate of 5-10% per iteration (recommended by "Pure Scrum" advocates Ken Schwaber, Jeff Sutherland and even Mike Cohn).

Fixed "scope" has some limitations in terms of its ability to represent value.  The Scrum process is intuitively appealing, because in real life, software value cannot be measured until the software is delivered to people who will use it.  If your team delivers EXACTLY what was described in the requirements documents everyone signed eighteen months ago, but nobody can actually use the software as delivered, someone didn't get the value they expected, and lawyers will determine who has to cover the costs.

Pure "trust me" time and materials based project approaches also have limitations.  Someone has to put some kind of stake in the ground, and in some organizations, "progress" needs to be measured in some way.  The classic scrum "burn down chart" showing how much planned effort has been delivered each iteration is not going to be satisfying to a business person with end of year bonus concerns, where that particular thing has a fairly large "minimum viable feature set."  Questions like "when can we ship" are valid questions.

"Astute" describes a submarine navigating in a specific direction without landmarks, and arriving at exactly the right coordinates when requested to surface.  Successful projects need to use a set of reliable techniques to balance out the need for some overall direction (we are building a wheel barrow, not the Empire State Building), with the need to be flexible about the details, and the ability to be pinpoint precise at delivery time.

• Models need to be created to help users and sponsors visualize the software more concretely than can be done from reading a formatted DOORS file.  
• Techniques need to be used to track the movement of the scope details within the guard rails of the overall project road map, if that variance is important for future planning models.
• Product owners need to assign value to the items as they are planned, using "value points," so you can chart the overall value a project delivers separately from the actual scope items delivering the value.  If you can get them to do this, you never need to understand their actual motivations.  Jim Highsmith's famous inverted "Agile Triangle" shows it this way:

From http://theagileexecutive.com/2010/01/28/use-the-agile-triangle-instead-of-the-balanced-scorecard/

3)  Just What Is It You Say You Do Here?  How Do You Brand Yourself if Your Goal is Invisibility?
Because the politics around project delivery are complex, and messaging is a huge part of project success, the vast bulk of what a professional value wrangler does every day is invisible, by design.  You aren't just building a product--you are building a perception around the product.  And as anyone who has delivered anything, anywhere, knows, perception is reality.

The best "Astute" practitioners, at sea, and ashore, don't publish "tell all" books about their journeys.

Bottom Line:  It is High Time to Brand, Professionalize and De-Stigmatize Astute Practices.

I don't know where the naming committee will come out on what to call this.  But this is an exciting vehicle to jump aboard, whether submarine or just band wagon.  New techniques are being born all the time impacting the "value" space.

• Continuous Delivery is the new coolest thing for developers to do, and it also creates a fascinating problem space to explore, which is twice as large for analysts, in terms of engineering their value hypotheses into their investments.  
• BDD, theories around test data management (synthesizing and masking), and combinatorialial optimized testing techniques create a discipline about how acceptance criteria should be structured, and how end to end tests can grow architecturally the same way code does, and in real time.  
• Lean startup suggests purposely experimenting, and changing direction altogether, when in a startup mode, and so on.

Scott Ambler famously dismisses the need for an agile team to waste money on professionalized value-tracking techniques as follows:

A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.

Remember, BA is also the abbreviation for band-aid.

Perhaps the time has come to re-occupy the two letter acronym, and take pride in branding and participating in "Being Astute." Interested?  Join us in the FebMeeting space:  https://plus.google.com/communities/117918808932484104617.