Risks coming in many categories!

Risks coming in many categories!

Some risks are fairly common. They pop up either as user stories, on risk logs or in conversations with team members. All risks need to be recognized, but not all risks are within the team’s ability to control or even influence. What a team can influence is how it reacts if a risk becomes an issue. Understanding common categories can help a team consider the risks they may face and whether they have considered everything they need to consider. A common taxonomy of risk categories is:

  1. Business Risk – Markets change due to changing tastes, regulations, and new discoveries, to name a few reasons. This is typically a difficult category of risk for technical teams to recognize, and is often recognized as changes and additions to scope. Inclusion of business product owner is useful to help a team to understand why change is needed and to provide leadership through prioritization. The groomed, managed product backlog is an active mitigation tool for this type of risk, HOWEVER business risk will exist for all projects.
  2. Technical Risk – Technology, like the business environment, evolves to generate risk. New projects that will require architectures and environments to be defined and implemented are fraught with risk (which is a reason many people buy commercial solutions rather developing their own). Maintenance and enhancement projects typically have the lowest amount of technical risk. Technical teams are generally adept at recognizing technical risks but are less adept at seeing when technical risks becomes an issue due to cultural biases. Agile techniques, such as short development cycles (sprints and program increments), test-driven development and continuous builds and integration, help to reduce technical risk.
  3. DevOps/Operational Risk – Many development teams and methods only play lip service or wait too late to consider how their software will fit within the organization’s operational environment. The organization’s operational ecosystem often includes operations, help desk personnel, IT personnel and business support personnel, such as training. Developing and testing a solution that no one can run or support is nearly meaningless. Barriers between organizational groups complicate recognizing and mitigating this category of risk in hierarchal organizations. Including DevOps personnel in project teams, in planning sessions (SAFe Release Planning, for example) and as active participants in demonstrations are mechanisms for reducing the possibility of this type of risk becoming an issue.
  4. Process Risk – Teams adopt and adapt techniques for delivering value based on organizational standards, environmental constraints and the problem they are trying to solve. Given that all projects have at least some unique characteristics, it is possible that the team’s common technique or the technique chosen may not be a match, causing risk. Consistent and honest retrospectives are useful for mitigating this risk and for minimizing the impact of process risks that become issues.
  5. Organizational/People Risk – Projects operate in an environment populated by people with all the possible caveats and footnotes that entails. The organizational/people risks can include personnel changes, dysfunctional office politics, conflicts for staff, multi-tasking and many others. Teams typically become blind to many of these risks believing that they can deal with these issues. Embracing stable teams and the Agile principles of self-organizing and self-managing teams are mechanisms for mitigating these types of risk.

Each of these categories can be further broken down to add focus on specific areas. Lists of risk categories and specific risks become less valuable when they are used as checklists that require each item on the list to be addressed. Having a set of risk categories is useful when they are used to direct thought and discussion about risk.

Did you anticipate the jellyfish or not?

Did you anticipate the jellyfish or not?

 

On February 12 at 5:44 AM a sink hole in Bowling Green, Kentucky opened up below the National Corvette Museum Skydome exhibit area swallowing eight cars. The risk of the sinkhole had not been foreseen; therefore no one had monitored the risk. The problem was discovered when a motion detector was triggered. The motion detector was in place to monitor and mitigate a more commonplace risk. I am convinced that the risk managers at the museum were convinced they had anticipated all reasonable risks. Every time methodologists, developers and project managers (of any stripe) decide that they have found the perfect process or method that risk-proofs their project that disaster is right around the corner. We have described how Agile mitigates some types of risks (Agile and Risk Management), however risk in general still needs to be managed and controlled in any size project. Software risk management is crucial to the success of all software development, enhancement and maintenance projects by avoiding problems that can be avoided and recognizing those that can’t be avoided. A lean process to manage risk in Agile projects is shown below:

  1. Identify knowable risks. – Identify the knowable risks when generating the initial backlog. Remember that risk identification, like the identification of users stories, will be an iterative process. Teams that have trouble identifying risks could leverage a checklist or a list of common risks.
  2. Build mitigation for common risks into the definition of done. – The definition of done is the requirements that the software must meet to be considered complete. Common risks such as the failure of the software to integrate properly can be built into the definition of done, which provides mitigation for the risk.
  3. Generate stories for less common risks and add them to the projects backlog. – Risks that can’t be mitigated and monitored through the definition of done can be treated as a specialized form of a user story and added directly to the product backlog.
  4. Review risks when grooming stories. – Just identifying and listing risks is useful, but not sufficient. It is necessary to review the risks placed on the product backlog.  The backlog grooming process provides a good platform for periodic risk review to ensure that if a risk needs to be mitigated steps can be added to the next sprint or that if risks are becoming issues that steps can be taken immediately.
  5. Carve out time during planning to identify emerging risks. – Project environments are dynamic. New risks may emerge or current risks evolve as the project progresses. Carving out time to reflect on risk as part of planning will help the team avoid being surprised.

Why is the discussion of risk important? Projects need understand what can reasonably happen and be prepared. While very few projects would have to plan and prepare to deal with a sink hole opening up and eating their data center or the project team (unless they were in Bowling Green) potential risks that are reasonable should be anticipated. In a world where most projects are integrated into an organizations value chain, potential disruptions or failures need to be explored and monitored.

The team shows what they have completed.

The team shows what they have completed.

Demonstrations are a platform for an Agile team (or teams) to interact with stakeholders in order to solicit feedback and direction from a broader audience. A demonstration satisfies three primary goals: communication, risk mitigation and motivation.

The format of a demonstration varies from one implementation of Agile to another; however the basics always include the team communicating the work that was completed during the sprint. This allows the team to showcase the value they are delivering.  It facilities a discussion of needs, desires, risks and concerns between the stakeholders and the Agile team, which enriches the team’s knowledge.

Demonstrating how the team (scrum master, product owner and technical team members) developed the solution for the work units at the end of each sprint avoids many of the classic risks seen in waterfall projects.  One of risks the that a demonstration mitigates is the risk of surprising the stakeholders with a solution that does not fit their needs at the end of the project. Feedback helps the team and the organization avoid building throw away projects by continually validating the direction.

Demonstrations provide a vehicle to generate or reinforce team motivation. Demonstration allow the team to publicly showcase the work they have completed, which generates a sense of accomplishment.  A sense of accomplishment based on tangible results is a type of a feedback loop that helps build team confidence and while creating or reinforcing motivation. My professional observations of teams strongly suggests that motivation and confidence are directly related to productivity and quality.

Demonstrations are a tool to generate conversation about what is being delivered.  Because a demonstration occurs at the end of every sprint the team will continually be demonstrating the value they are delivering, which reinforces confidence and motivation. The act of demonstrating value provides the team with a platform for collecting feedback that will help them stay on track and focused on delivering what has the most value to the business.