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.

 

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.  

 

Incorporating the Idea of External Risk into Agile Efforts

A spider web has several external risks.

Making sure external risks are addressed in an Agile effort, or any effort for that matter begins with making sure that at least a basic risk management approach is in place. If a basic risk management approach is in place we can integrate the concept of external risks.  Everyone involved should understand the basics of the risk management process being leveraged on the effort.  All risk management processes need to identify who is responsible and how the process fits into the value delivery flow.  Specifically, incorporating the idea of external risks into the process is typically more urgent as the scale and duration of the effort increases if for no other reason than longer efforts are exposed to the trials and tribulations of the outside world longer than small efforts.  The size of the effort affects two main variables used to scale  Agile risk management.  The larger the effort the greater the need for the people involved with the effort to define who is responsible for risk management and how much process is needed to keep things organized.   The size of the effort, while a continuum, will be represented by small efforts (one team and a few iterations or sprints) and large efforts (over 75 participants with at least 6 iterations or sprints) for illustration.  

 

Internal and External Risks

Having a plan mitigates risk.

Risk management is crucial to the success of all software development, enhancement and maintenance projects.  Risk management at its basest level is avoiding problems that can be avoided and recognizing those that can’t be avoided. In order to recognize and avoid problems, every project must take the steps that need to be taken to consciously look outward and forward. The act of risk management requires both introspection and extrospection.  Extrospection, a rarely used word in the everyday conversation, is even rarer in many Agile approaches. One important way to assess risk is to consider whether there are internal or external risks.

 

SPaMCAST 405 – Moral License, Hazards, Change and Innovation, Assumptions, Test Scripting

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

Software Process and Measurement Cast 405 is a cornucopia of topics!  We begin by exploring a bit of the psychology of change in four short essays. These topics are important for any change agent at any level to understand. Change at any scale is not an easy task. Change requires establishing a goal, recruiting a sponsor, acquiring a budget, developing a set of plans and then there is the part where the miracle happens and people change. The last step is always the hardest and is often akin to herding cats. Psychology and sociology have identified many of the reasons why people embrace change and innovation in different ways.  

Our second column is from Jon M. Quigley.  We have settled on a name for the column, “The Alpha-Omega of Product Development.” In this month’s column, we discuss using metrics to dispel assumptions. Metrics don’t have to add to overhead, for example, one item we discussed was using planning poker to expose assumptions and then to find tactics to address them.

Anchoring the cast, Jeremy Berriault brings the QA Corner to the Software Process and Measurement Cast.  In this installment of the QA Corner, Jeremy talks about whether test automation scripting for new functions should be tackled or not.  Jeremy has an opinion and provides advice for testing professionals on a sticky topic.  

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 12 and 13.  This week we tackle two concepts central to XP: planning and testing both done the XP way.