That which can’t be tested doesn’t exist… or must it?

That which can't be tested...

When I first read Martin Fowler’s Refactoring: Improving the Design of Existing Code, I stumbled on the phrase “That which can’t be tested doesn’t exist.”

In the years that followed, it has been something of a mantra to me, though I’ve found many things that made testing simply impractical.

What I want to do in this post is flip my earlier quote ON ITS HEAD!

Here’s a new category for ya!

In the category of not-really-a-corollary-but-it-makes-your-head-spin-to-think-of-it (dare me to add THAT to my blog categories!), Martin Weigel wrote in Restating The Wearingly Obvious, “You can’t test what doesn’t exist.”

That is flippin’ AWESOME! What he calls “wearingly obvious”, he describes in much more detail to be somewhat of a side effect of common sense thinking that we have ignored (in his case in the advertising industry) for over 30 years!

Here are a couple of key quotes and ideas from his writing that I see as relevant to the software industry:

  1. The idea that we can test “rough ideas” allows people to “abdicate their personal judgement and taste”, in other words, to “pass the buck” – what happens to the agile project without Metaphor or increasingly refined requirements?
  2. “Until you actually have finished work you are not testing creative solutions” – Hmm… sounds familiar (but not the same)?
  3. “Incomplete ideas evoke rough, incomplete responses from people” – even though he is writing about advertising, isn’t it important that what we test in agile is “true”, and that the reliability of our tests is related to some notion of completeness in the scenarios we anticipate?
  4. “Any research is therefore as authoritative and as fallible as the individual judgements and opinions of those involved in the [advertising] process.” Amen to that!

From Martin's post: did he identify an Archimedles?

Software development is creative work

And then he ends with a couple of really great sentences:

“There is no methodology in the world that can remove the element of uncertainty from the development of creative work. However much some might wish that to be the case.

“All creative decisions ultimately involve a leap of faith. And that requires more than simple courage. It requires people with taste and vision. People with the imagination and sensitivity to think ahead and be able to picture what has not yet been created.

“If you are unable to grasp these simple truths, if you slavishly believe rough responses to rough work to be The Truth, and treat them as directives for creative development, if you are uncomfortable with the notion of taking a leap of faith… then you are not one of those people. And you are very probably in fact, in the way.”

Wow! I hated quoting so much of his material here, but my challenge is that you look beyond the advertising domain he is writing about and think about the implications to software development.

So how does this trigger you? Let me know with a comment.

A fourth rule for agile project managers

Sincerity, reliability and competence to hold promises

The “Top Three Rules for an Agile Project Manager“, according to Terry Bunio (bornagainagilist), are:

  1. Team velocity
  2. Client interaction
  3. Deliver something personally

…I see that as a great list, as long as the client is ready to accept delivery of the product when the release is ready.

Now, maybe it’s different for software companies that have made a commitment to agile practices. When professional services teams shift from one client to another, though, accepting delivery can’t be taken for granted.

That a client accepts delivery of the product is a matter of trust, like so many other aspects of trust that show up within and among members of the agile team.

There are at least two common themes I have seen when clients hesitate to accept a product that has otherwise satisfied releases requirements:

  1. Sometimes early in a release cycle, or even after a couple releases, a deeply ingrained history of unmet expectations from earlier software projects can make a client less willing to simply accept the product.
  2. In addition, it can seem to some clients who are concerned to continue getting new features in the future that they need to have everything crammed into the current release.

In both cases, the psychology of the customer could be oriented around either threats of undiscovered defects or of losing potential opportunities.

Declining product delivery is a trade-off weighed against the potential that these threats could materialize.

The agile project manager can preempt the trade-off by acknowledging which potential threat may exist and working in advance to mitigate the risk.

The good news is that it turns out the key to mitigating both of these threats is also a form of trust: in the first case, it is trust in the quality of the release… and in the second case it is trust in the iterative nature of release planning.

No surprises, no panic

Throughout the first release, the agile project manager works through iteration planning meetings, retrospectives, stand-ups, and other forms of status and communications to reinforce the close relationship between the development team and the product under development.

There are zero if any surprises, and when executed strategically there are many opportunities to show and build trust with your customer throughout the release cycle.

Each opportunity to build trust is highlighted and emphasized so that everyone knows we are sincere, competent and reliable to keep the promises we make (or make amends quickly and effectively).

In addition, while the project manager must keep everyone directed and focused on the features of the release, s/he cannot lose track of the place this release plays as a tactic within the customer’s larger goals. If we do not expect this is a final release, then it always fits into an ongoing story with each release achieving one strategic objective or another.

We ship early, we ship often, we ship quality, we ship value. It’s a good life.

What strategies or tactics do you use (or could you envision) for helping a customer accept delivery of a release if they show signals of reluctance? Can you anticipate reasons other than the two I outlined, and how might you address them?