Hour 21
Deploying for Progress
What You’ll Learn in This Hour:
Summary and Case Study
In previous hours, we tested, subsequently improved, and continued to iterate on our product or solution, oftentimes for a small audience as a way to learn and refine. In this hour, we go beyond the basics of deployment and consider what it means to deploy products and solutions when we find ourselves stuck. After briefly discussing perfection traps, we turn to three novel techniques for regaining velocity in the wake of stalled deployments. Then we cover two edge case techniques that may be useful when product or solution complexity affects deployment velocity. We conclude Hour 21 with a “What Not to Do” case study focused on the real-world lessons of deploying too soon.
Avoiding Perfection Traps
As we know from previous hours, we cannot simply iterate and iterate again until we have a perfect solution. Perfection does not exist; there is always more work to do, more features to develop and deliver, and new needs to understand and surface in the solution.
- Design is never fully complete. We need to draw a line in the sand, however, and claim that design is complete from a release perspective. Subsequent design change requests need to be placed into the backlog for the next release.
- Development is therefore never fully complete either. But we still need that line in the sand that claims feature development for now at least is complete from a release perspective. New requested features need to be pushed to the next release.
- Testing of a release in all of its required forms can be tempting to continue ad infinitum too. But we eventually need to claim that testing is good enough.
- End user training and other responsibilities related to solution readiness and adoption are similarly affected by the desire to be 100 percent ready and the need for just-in-time training and readiness and access to help that allow for something less than 100 percent readiness.
The key to avoiding perfection traps lies in setting and managing expectations. Having the right conversations at the right time with the right people will set us up for success. Nearly always, people prefer that we make progress, and they generally buy in to that perspective when we’ve had the right discussions and talked through the trade-offs. While perfection is the enemy of progress, good enough is its ally.
Novel Techniques for Making Progress
Earlier in Hour 17 we explored the Progress Mindset and a host of techniques for making progress focused on starting small, delivering small bits of value quickly, and organizing the notion of value around a set of Objectives and measurable Key Results.
But what if there are fundamental challenges to delivering at all? What if we need to step back and do something different before we can become the progress makers we’re hoping to become? In these cases, we might wish to first try a set of precursor techniques, explored next. String these three techniques together to create a recipe for making progress when other methods seem insufficient or have proven ineffective.
Design Thinking in Action: Fixing Broken Windows
Before we can make progress, we might need to first slow down and fix the “broken windows” surrounding our teams and our users. Based on criminology and social theory, the Broken Windows Theory states that visible signs of unresolved neglect or bad behavior promote greater neglect and worse behavior. Conversely, as criminologists James Q. Wilson and George L. Kelling shared in The Atlantic Monthly in 1982, if we address the small transgressions and evidence of neglect around us, the likelihood for greater transgressions and neglect nearly disappears. Bad behavior begets worse behavior, and good behavior begets better behavior.
So when it comes to making progress, step one for our tech teams might be as simple as setting the project or initiative aside and first cleaning up and organizing the workplace…or fixing the site’s broken internet…or restoring the free-coffee-at-work-for-everyone benefit that naturally dried up during the pandemic. And for our user communities, the team that comes in and literally fixes the broken workspaces and cleans up the shared spaces before moving in has a better chance of building positive sentiment and buy-in. When we invest in becoming part of the solution early on—when we employ the Fixing Broken Windows technique—others will remember and respond to that.
Design Thinking in Action: Avoiding the Abilene Paradox
In 1974, Jerry B. Harvey wrote an article called “The Abilene Paradox: The Management of Agreement” where he shared a story about a family of four comfortably sitting around in the hot Texas heat playing the game of dominoes. One of the family members, concerned the others were growing bored of the game, suggested they all drive an hour to the nearest city, Abilene, for dinner. One by one, the remaining family members agreed, operating under the belief that the others probably also wanted to drive an hour or more in the heat to go to dinner.
As it turned out, no one actually wanted to go to Abilene. The family wasted several hours driving there and driving back. Worse, they had an awful dinner that left no one satisfied. And four hours after leaving they found themselves in the same place as before, as we see in Figure 21.1, having made no progress whatsoever.
FIGURE 21.1
When we fail to poll others and vocalize our own true wants and needs, we risk consuming precious time and energy yet going absolutely nowhere a la the Abilene Paradox.
The lesson or takeaway is simple: We need to draw out people’s true wants and needs before making decisions that cost the group time and progress. When we are faced with taking a journey that may or may not be necessary, consider how to poll the group in a discreet or anonymous manner to validate their true wants and needs. We need to vocalize our own true wants and needs too! And we might be surprised at what we find. More importantly, like taking an unnecessary trip to Abilene, we may avoid the kinds of detours and anti-shortcuts that kill progress.
Design Thinking in Action: Reducing Cognitive Load
Sometimes we fail to make progress simply because we are overwhelmed with too much to consider and think through. Too much cognitive load undermines or slows down people and teams that otherwise know what they need to do next. Excessive cognitive load can rob us of the ability to take the Next Best Step as we understand it today, and instead think and consider about x and think and consider about y.
The Reducing Cognitive Load technique is simply about recognizing and reducing the extraneous load that we are placing on ourselves and others. Once we have completed our thinking and ideation, what can we do to turn the corner from thinking to doing? How might we focus afresh and begin to execute? How might we need to think or operate differently to kick-start the doing?
For example, we might find it useful to Time Box our cognitive activities to create a clear stopping point or Forcing Function for moving forward and getting the work done. These are important considerations and questions to answer when we find ourselves stalled or stuck. Remember the power of “doing” and take the steps necessary to turn that corner!
Edge Case Techniques for Deploying and Realizing Value
Just as we read in the previous section, we have techniques at our disposal to help us preserve or regain velocity. Two such edge case techniques may be useful when deployment itself of a complex product or solution proves too challenging.
Design Thinking in Action: Backward Invention
Sometimes the weight of complexity holds us back from deploying value. As we have seen in numerous examples and case studies throughout the book, our desire to bring maximum value to our users and customers can keep us in limbo. We might wait for more sprints to be completed, or for a user interface to be perfected, or for data loads to complete without error, or for our MVP to get a collection of last-minute features. Surely, there are cases when this kind of waiting is warranted.
In many cases, however, it’s the waiting that keeps us from deploying and realizing value. It might be time in those cases to practice Backward Invention as a way to again make progress. Backward Invention calls for us to strip out features and complexity as a way to simplify a design, prototype, or MVP, as we see in Figure 21.2. Such an exercise targets the features or capabilities that we continue to struggle with, features and capabilities that our A/B Testing, Structured Usability Testing, and other early testing reveal we still don’t have right. When a user shares with us in a Solution Interview that a particular feature is irritating and should be removed, do it. Follow their advice, if only for the short term. And continue refining and iterating with the smaller community those irritating and questionable items so that one day we can again build atop our stripped-down design, prototype, or MVP.
FIGURE 21.2
When deployments are stalled, Backward Invention can take us to a place where we can at least make some progress while we work out complexity and other details that are holding us back.
Design Thinking in Action: Balancing the Essential and the Accidental
Sometimes in our deployments we find that complexity is interfering with value realization. Truly, we should have discovered this type of situation earlier through feedback gathered from prototyping, testing, MVPs, and Pilots. But these things happen, and when they do, it is important to be able to step back and consider:
- From where does the complexity come?
- Is this complexity absolutely essential?
- Is the complexity accidental, the outcome of another decision or an oversight?
- Is there a lighter-weight design, interface, or deliverable we can quickly turn around while we solve this complexity problem properly?
The value of the Balancing the Essential and the Accidental technique lies in helping us think through what is truly required from the complexity in front of us. As we consider a complex idea, design, interface, deliverable, deployment process, onboarding method, and so on, it is important to understand the complexity that can be removed versus the complexity that is necessary. There is often a vague line that separates the value found in an idea, design, or interface, for example, and the loss of that value. This line separates the essential from the accidental, the required from the unrequired or optional, as we see in Figure 21.3
FIGURE 21.3
Identifying the fine line separating what is essential from what is accidental can help us find unnecessary complexity and strip it out to make progress again.
Based in philosophy, how might we apply the Balancing the Essential and the Accidental technique to our work products? How might we learn to recognize this thin line separating the essential from the accidental?
- Some features are more essential than other features. Do we have traceability back to those features deemed essential early on by a user community?
- Forced ranking can help us find the line between the essential and the accidental. Can we use the Buy a Feature technique outlined in Hour 13 to force users to “put their money where their mouth is” and thus create a line between what is “funded” and therefore essential and what is not?
- Evaluations and discussions can also illuminate the line between the must-haves and the nice-to-haves. Can we find that line through an anonymously administered survey?
To be clear, we oftentimes find the accidental to be useful. We may even depend on such accidental items. Consider how certain ways of displaying data in reports, for example, can be accidentally introduced in a sprint. Our users might find such an accidental approach to reporting useful and capitalize upon it. Weeks or months later, after removing such an accidental feature in a subsequent sprint, we might suffer backlash from those who came to count on that feature. Regardless, as we come to better know our users through their production feedback (consider again Gathering Silent Design Feedback from Hour 20), we might include those newfound or newly understood needs into our sprint backlogs and release plans.
What Not to Do: Deploying Too Soon
We have frequently highlighted the need to avoid perfection. But the reality is that people and teams are often more inclined to deliver something—anything—than nothing at all. Teams want to prove their worth after all, and business executives and sponsors naturally tend to push (rightly so) for value realization. In the world of prototypes, MVPs, and Pilots, deploying early and often is absolutely the right mindset.
When it comes to deploying our product or solution for our broader user communities, however, deploying too soon presents another problem: user perception and adoption. That is, if the product or solution is not fully tested and “baked” and we have not properly set such expectations around our poor baking skills, then our end users will quickly reflect perception and sentiment problems with our work on day one. And within several more days, if nothing changes, we might risk losing our users as they fight against adopting our product or solution at all.
Such examples are all too common, and they typically reflect a waterfall approach to development and deployment. Consider the story of a large pharmaceutical company that worked on its Enterprise Resource Planning (ERP) solution for over three years. After spending $60 million on consulting and licensing fees and introducing the solution to a small team of senior and presumably influential users, the company finally deployed the solution to its broader community. And it found out on day one that this huge investment failed to meet many users’ expectations in terms of look and feel, functionality, and performance. Why? Because the ERP project and business teams failed to do the kinds of Design Thinking–inspired activities that help us circumvent such outcomes.
There was little prototyping, for example, and zero demonstrations beyond a small subset of friends and family. The company declined to run an MVP for fear of revealing a fully functional system, and it decided against a Pilot under the mistaken belief that its show-and-tell demonstrations were nearly as effective and much less costly. In the end, the pharmaceutical company spent well beyond what it budgeted to simply remediate the gaps between what was built and what its end users expected.
Summary
In Hour 21, we assume we can finally deploy our product or solution for broader use. After briefly discussing perfection traps, we covered three novel techniques for making progress when progress stalled or we got stuck: Fixing Broken Windows, Avoiding the Abilene Paradox, and Reducing Cognitive Load. Each technique covered a unique challenge related to deployment progress. Then we outlined two edge case techniques useful when deployment of a complex product or solution proves too challenging, including Backward Invention and Balancing the Essential and the Accidental. We concluded Hour 21 with a “What Not to Do” case study focused on the lessons of deploying our products and solutions to production too soon.
Workshop
Case Study
Consider the following case study and questions. You can find the answers to the questions related to this case study in Appendix A, “Case Study Quiz Answers.”
Situation
Your sponsor and the Bank’s Chief Digital Officer, Satish, has been concerned about deployment slips and surprises. Some of the excuses have him concerned that two of the initiative leaders may have overengineered their solutions. In other cases, Satish is worried about the pursuit of perfect testing and training. You reminded him that there are many techniques and exercises for thinking through deployment issues and restoring progress.
In response, Satish has organized a workshop with all of the deployment specialists who float across the Bank’s OneBank initiatives. He would like you to cover new techniques or methods beyond deployment itself, novel techniques that really focus on recovering stalled deployments and regaining lost velocity.
Quiz
1. What are four examples of areas that many organizations struggle with when it comes to avoiding perfection traps?
2. Which technique reflects the premise that bad behavior begets worse behavior?
3. What is the moral of the Abilene Paradox story?
4. Which Design Thinking technique presumes that simplifying a product, solution, or service can help adoption?
5. What does it mean in philosophy or Design Thinking to work at Balancing the Essential and the Accidental?