Adaptability Requires Comfort With Uncertainty

Making decisions is exhausting. It involves perception and analysis, and most of all: taking responsibility.
Mental load and the worry cache, Seth Godin, June 15, 2017

In most organizations, software development and maintenance is not a solitary activity.  Even a relatively simple enhancement require the involvement of multiple roles to identify, translate and implement an idea.  Teams are the tool used to effectively gather and coordinate all the needed roles in one place. While it is easy to perceive the team as a monolithic unit, every individual on a team is a decision-making machine.  Each person will have a different tolerance for uncertainty and ambiguity which will affect how they make decisions.

Advertisements

 

Uncertainty in Planning/Budgeting/Estimating

Uncertainty is a reflection of human’s ability to think about and then worry about the future.  The future, whether tomorrow or next week generates cognitive dissonance because we are afraid that what will happen will be at odds with our mental model of the future. Budgeting, estimation, and planning are tools to rationalize away uncertainty; however, they have a complicated relationship with uncertainty.  For example, in some scenarios some uncertainty helps to prove the veracity of an expert, and in other scenarios uncertainty can generate cognitive dissonance with the assumption of certainty built into budgeting, estimation, and planning tools organizations use.

 

Storytelling Techniques: Business Obituaries

An obituary was written when a queen was interned

In keeping with a slightly morbid bend in storytelling techniques, we add to the premortem technique the idea of a business (or project) obituary.  An obituary is a specialized form of a news story that communicates the key points in the life or a person, organization, event or project. During my college years, I spent time in college radio stations on air both playing music and doing the news (where do you think the podcasting came from? Check out the Software Process and Measurement Cast).  In the newsroom we largely knew how to put together an obituary.  We kept a few critical local celebrities written and ready just in case (in the business, this is called a morgue).  Just like any story an obituary is comprised by a set of attributes.  A typical (simplified) set of components found in obituaries (Chapter 51 from the News Manual – Obituaries) includes:

 

Story Telling Techniques: The Premortem

Identify the risks before you start with a premortem.

Storytelling generates the big picture to guide a project or to help people frame their thoughts. A story can provide a deeper and more nuanced connection with information than most lists of PowerPoint bullets or a structured requirements documents. Storytelling can be used as a risk management tool.  Premortems are a useful tool for helping project teams anticipate risks.  Premortems were described in the Harvard Business Review, September 2007 by Gary Klein.  The basic premortem approach can be can be customized with storytelling to increase the power of the technique.

 

Big Bang Change Initiatives: The Cons

 

Big Bang

A big bang adoption is an instant changeover, a “one-and-done” type of approach, in which everyone associated with a new system or process switches over en masse at a specific point in time.  Big bang process improvements are useful; however nearly every person involved in planning and executing change avoids them like the plague.  Practitioners avoid big bangs for a number of very specific reasons although at the root of these reasons is risk.  They are risky because they have:

 

Agile Risk Management: Recognizing Risks

You can’t capture risk with your camera. You need to have a conversation with a diverse group of stakeholders.

At a recent Q&A session I was asked: Where could a person get their project risks? I stifled a smart-alecky answer that would have included driving to the grocery store, and decided that the question that was being asked was really: How do I go about recognizing and capturing risks? Perhaps a more boring question, but far more important. If I answered the first question the answer would have been that risks are generated by the interaction of the project with other projects, applications, the business, technology and world (risk categories) – pretty much the existence of a project could be considered a risk magnet. The answer to the second question is that once you have a risk magnet (a project) you will need to ask as many different people as is feasible to recognize the possible risks. The discussion of risk is always appropriate; however, the typical meeting/events and the types of people to consider in the conversation needs to be planned. The discovery process typically follows the requirements/user story discovery process outlined below.

 

Discovering Your Team’s Risk Tolerance

Risk tolerance can be visualized as a curve. Above the curve represents a combination of high probability and a potential negative impact that will prevent the team from accepting the risk. Below the curve, the risk is deemed acceptable.  Outside of a few psychologically damaged individuals, everyone has a risk curve (whether they know it or not). On a team, everyone’s natural risk tolerance differs.  Complicating the discussion is that risk tolerance changes depending on context the person or team faces.  For example, at one point in my life riding my bike down a hill at top speed to see if I could slalom stop at the bottom was an acceptable risk.  I have the scars to prove I was that silly. Thinking back, I am not sure why I am alive today.  My risk tolerance is different now. While reminiscing about my unsafe days as a seven-year-old is fun, what is more important is to recognize that the same lesson can be applied to teams and in organizations. This leads us to the conclusion that we must talk about risk tolerance.