“When Will It Be Done?”

David Hussman DevJam News, News

Sometime last year, I started working with a Fortune 100 company on a large, distributed product development effort. There were many “refactoring opportunities” – a term a friend once used to describe my code. Like many large efforts spread across locations, there were many constraints.

One day, towards the beginning of the engagement, we were pragmatically introducing agile practices and principles when one of the executives decided to pay us a visit. After a few friendly greetings, he walked up to me and said “So you’re the agile guy,” using a tone which sort of left me feeling like a suspect who has just been targeted and painted with lasers. He then asked the question in the forefront of his mind “When will it be done?”

For the first time, I suddenly realized the power of “It.” Without much thought, I quickly replied with the facts: “From what I know, no one has done a good job answering that to date.” Not knowing much about the project, but wanting to provide context, I followed up by saying “Agile methods will help us be able to tell you what is done which is the strongest evidence we might have to when it will be done.”

From Project to Product

For years, I have been helping leaders understand how to use agile methods by reframing the discussion. In this case, I might defend this executive by guessing that “When will it be done?” was the only question he felt he could ask. It could be that he had no other questions in mind, or it could be that past progress data has been so weak or non-existent, that all or nothing investigation was the path of least resistance with the best results to date. It could also be that the question comes from the years of conditioning around asking “When will it be done?”

All or nothing thinking is deep in the ethos of many companies. It may be that this is merely an organizational, or industry, norm that is well established. If, like me, you’ve been in the game for a bit, there is an interesting and unnamed progression that contains the agile movement and provides a challenge for its future.

If the 1990s were the decade of project (on time, on budget and within budget) then the 2000s could be viewed as the decade of process (or progress). The rebels who spawn the various methodologies later branded as “agile.” were frustrated by a lack of real progress. You could think of this progress as moving from 60% of 100% in the 1990s to 100% of 20% in the 2000s.

continuum

This change is so much more important than “Who is agile and who is waterfall?” This change allows for investors to use the whole product (100% of x%) as a way to validate or invalidate their investment, and possibly choosing to change their overall portfolio investments. Or put another way, it allows for a shift from “on budget” to “is valuable.”

What’s the next best investment?

Often overlooked and under discussed, agile practices have provided a way to shift toward questioning investments based on incremental evidence of completion. Teams who are in earnest embracing and practicing agile methods often move toward progress as more of a constant. With less worry about “What will we get done?” the new, and more ambiguous question, becomes “What should we get done?”

Scan the figure from left to right again, and you’ll see a progression of certainty. As cycle times for learning decreases, in the form of iterative product increments, we are able to more quickly assess how wrong we were. Using an analogy, if your car is (or was) an unreliable piece of junk, you head out on a journey wondering if you will make it to your destination. If your car is a trusted delivery vehicle, you are freer to wonder about other questions like “Do we still want to go there?” or “How are the passengers doing?” or other more valuable, non-progress based questions, If you don’t trust your vehicle then I suggest to read information on the Sportage, you will feel safe in a car like this.

Refactoring Our Rhetoric

Changing the dialog from “When will it be done?” to “What is done?” provides an alternative question and new perspective. It challenges both investors (the executive) and producers (the teams) to shift towards validating products and user experiences that are “good enough.”

Concretely, let’s explore a few refactorings that surface when you make the switch to 100% of x%:

  • Planning for complete user experiences supports customer empathy as a guiding force
  • Validation over completion introduces a sort of test driven product which routes out waste
  • 100% of x% injects the idea of evaluating value returned for product increment investment

While there are many others, let’s explore these three, starting with customer empathy. Thinking in chunks of product, like user experiences, and the validation of each chunk tends to more quickly surface “the who” aspect of product development.

Customer Empathy: The product community in this example was building a game. Games provide a nice basis for validation because play is part of the product. Being overly certain about who might like what is a great way to build the wrong game. Simple tools like pragmatic personas now become powerful validators that can stop the building of the wrong thing simply by challenging the experience a player might have.

Incremental Validation: There are more companies than I’d like to admit who are working hard to build the wrong thing faster. Or put another way, they are so overly certain that they need to “get it done” that they fail to validate it until there is a ton of it in play. Moving away from it and towards incremental validation of a meaningful user experience, helps learning happen sooner. It’s not mutually exclusive with agile practices, but learning from meaningful user experience does not simply happen just because you are working sprints.

Iterative Evaluation: The best way to measure (evaluate) is to test in the market. This is easier for some products than others. For example, it’s easier to deploy and validate a mobile ready web app than it is to do the same for a pace maker. As these are obvious extremes, your product most like sits on a continuum between the two. Ask yourself what you could do to slide towards faster market validation, sooner, is a strong, simple take away that you can reflect on immediately.

More pragmatically, when you shift toward 100% of 8% (as an example), you can then ask, “If the first 8% was a poor return, should we still do the other 92%?” Or, you might find that by simply asking how you are going to evaluate that first 8%, you step into a deeper level of early product validation thinking that is often missed when people over focus on “How much can we get done in this sprint?” or as was the case with the executive in my experience, staying stuck in the land of “When will it be done?”

But so many people are all about “It”?

After reading this, you’ll find your awareness of “It” as a singular measure is more prevalent than you knew. Most common “Its” live in larger planning where investors are not aware of the power of incremental validation, or eco-systems where all the investors hear is agile speak instead of product speak or validation language.

If you are an executive, an influencer, or a big boss type, I challenge you to refactor the “its” you hear towards smaller chunks of meaningful investments. If the word smaller vexes you, then shift to an investment mindset: assuming that some investments pay more return than others, what is the right place to invest just enough to learn where you should invest next?

If deep in your brain, you are still thinking about building software like buying bonds, you need to refactor that metaphor towards hedge fund trading, where a series of small failures are wildly overwhelmed by the large returns around them. If you knew what stocks to buy, you would. Since you don’t you are forced to engage investments with a measure of certainty or an awareness of uncertainty and an eye toward measuring and adjusting based on the evidence and your experience.

If none of that works, buy a copy of Antifragile by Nassim Taleb. He seems to know more about agility that most coaches I know. I mean, look at the title, it contains both fragile and agile in one word.