Risks

Risks are indicators that something negative could occur with how and organization is working or how solutions are being built. Risks can occur because of the activities that are or are not happening. Our software solutions have different impacts but the all share the common risks in the image above. Currently, the Waste, Opportunities, and Risk Engine (WORE) is able to identify 473 unique risks.

	Risk	Context/Purpose	Examples
	Not Categorized	Risk that has been systemically detected but unable to definitively categorize it
	Cost	Risks of this kind indicate greater than expected burn rate due to the typical of activities being performed or how they are being executed.	Manual activities can can be automated Non-value added activities Lack of activities that likely lead to defects
	Cultural	These types of risks indicate concerns the organization should have regarding its culture. Organizational cultural is the last aspect of an Agile / DevOps transformation to be realized because requires change in mentality, habits, and trust then most people are used to. Cultural risks can exist because of an activity or a set of activities but often will be identified because of a model lacking activities or how they should be executed.	Lack of collaboration like reviews Too many meetings Meetings in every phase Lack of automated activities
	Customer Satisfaction	Risks of this nature should be resolved / mitigated as they appear because customer satisfaction is arguably the most important metric for the organization.	Time-to-Market Quality
	Model	Risks of this kind indicate logical problems in a model that should be corrected before proceeding.	Building before checking-in code Unit testing in a production environment Deployment activities in the pre-commit phase
	Planning	This type of risk indicates the plan(s) to deliver customer value are likely to be delayed. Typically, the delays are caused when there are insufficient testing activities early in the process which results in remediation being more complex and time consuming.	Defects due to lack of proper upfront testing Defects or technical stories for remediation of poor non-functional requirements discovered in production
	Policy / Regulatory	Indicates risks based on an activities, set of activities, or the lack of expected activities to meet policy and / or regulatory minimums.	Lack of security testing Lack of accessibility testing Lack of documenting release notes
	Quality	These types of risks most often indicate insufficient or outright lacking of testing earlier in the development and delivery cycle.	Lack of unit and / or integration testing Lack of automated tests Lack of Continuous Integration
	Scope	Risks of this type indicate scope will likely increase due to defects and insufficient testing of non-functional requirements.	Lack of security testing Lack of performance testing Lack of unit or integration testing
	Team Satisfaction	Lack of team satisfaction can easily result in reduced quality and greater than expected turnover in personnel. If not recognized and resolved quickly, low team satisfaction can negatively affect organizational cultural, cross-team satisfaction, and overall efficiency.	Amount / Percentage of manual activities to deploy solutions Low quality that results in continual defect fixes Outdated tools
	Technical	This type of risk typical relates to changes in technology or unsupported technology but should also be considered for technology / tools that are not scalable or industry standards.	Unsupported version of an xUnit framework like NUnit or JUnit Unsupported data platforms like dBase or Sybase Non-scalable data platform like Microsoft Access Custom-build Continuous Integration platform
	Unforeseeable	This is the typical 10% of things that could not even be thought of as a possibility by the teams. The ADF does allow risks to be categorized as unforeseeable but suggest it would be a better practice to better understand the activities in the models and more concrete risks.

 Cost

Risks to the overall cost of a solution should be a concern whether its a fixed price contract or not. There is generally an understanding that initial cost estimates are a Rough Order of Magnitude (ROM) but we would be best to treat this as if was our own personally money and wanted to attain the most value with the least investment.

Suggestions:

1. Identify non-value added activities and eliminate them
2. Identify activities that can be reduced in scale and time and do so
3.  Automate manual activities
4. Reduce defects with testing concentrated on eliminating them vice finding them (e.g. Unit Test & Integration Testing)
5. Implement Continuous Integration (CI) in order to reduce integration complexity and have more “ready” code every day
6. Utilize Static Code Analysis as part of the CI process in order to quicker identification and remediation of vulnerabilities and weaknesses
7. Implement Continuous Delivery (CD) in order to ensure a consistent approach to delivering artifacts and testing them
8. Implement Continuous Deployment or if by policy not able to, implement Single-Manual Click Deployment

Go to Top of page

 Cultural

Risks of this nature indicate concerns the organization should have regarding its culture and set goals and objectives to become a truly Agile or DevOps organization. The Lifecycle Sleuth generally triggers this type of risk because of an activity or a set of activities but often will be identified because of a model lacking collaborative or learning tasks.

Suggestions:

1. Establish team working agreements for peer reviews and / or code reviews as close to development process as possible
2. Establish retrospectives at the end of a major event (good or bad) in order to learn and improve
3. Trust the processes by automating them including testing
4. Break builds on testing deficiencies to build a culture that favors quality
5. Eliminate “checking-in” or “status” meetings in order to build trust
6. Eliminate manual stage gates to copy artifacts into follow-on environments
7. Eliminate testing that just makes folks “feel good”

Go to Top of page

 Customer Satisfaction

Risks to customer satisfaction are best resolved or mitigated as they appear because this is arguably the most important metric for the organization. Ideally, your organization will be transparent with risks and issues and open to collaborating with the customer to determine if (1) they even care and (2) opinions on how to make them feel more comfortable. A collaborative customer is one that is likely to always work through problems with you rather then blaming and being punitive.

Suggestions:

• Fully collaborate with the customer on risks and issues
• Decrease time-to-market
• Increase frequency of releases to pre-production and production
• Decrease defects, vulnerabilities, and weaknesses by investing with more upfront automated testing

Go to Top of page

 Model

The Lifecycle Sleuth triggers these risks when it identifies logical problems in a model. If these risks are identified the suggested best approach is to modify the model to eliminate these before proceeding with anything else.

Typical Causes:

• Activities that appear out of order (e.g. compiling or building in the production phase)
• Automated activities that are really manual (meetings, reviews, etc.)
• Manual activities in the CI phase
• Phases with no activities

Go to Top of page

 Planning

Risks of this type indicates that plans to deliver customer value are likely to be delayed. Typically, the delays are caused when there are insufficient testing activities early in the process which results in unplanned remediation. As well, unplanned remediation efforts late in the development process are more complex, time consuming, and costlier than if they were discovered during developing and initial testing.

Suggestions:

1. Emphasize on the need to prevent defects with unit testing and integration testing
2. Establish team working agreements to have unit test code coverage of ~80% for new and refactored code
3. Establish team working agreement to break builds when unit tests and integration tests fail in order to address problems earlier
4. Utilize Static Code Analysis to identify vulnerabilities and weaknesses early in the development process

Go to Top of page

 Policy / Regulatory

Risks regarding policy or regulation are most often indicators of missing activities to meet these needs. Anything policy or regulatory needed should be considered as non-functional requirements.

Suggestions:

1. Document policy and regulatory needs for production releases for everyone involved in order to provide shared knowledge of these requirements
2. Collaborate to determine ownership of policy and regulatory requirements
3. Collaborate to identify and document policy and regulatory requirements so they can be incorporated into the Definition of Dones (Release, Capability, Feature, etc.)
4. Collaborate to determine activities that can be automated to best ensure policy and regulatory requirements are met

Go to Top of page

 Quality

Quality risks are most often triggered by expected testing activities and / or how they are being executed.

Suggestions:

1. Emphasize on the need to prevent defects with unit testing and integration testing
2. Establish team working agreements to have unit test code coverage of ~80% for new and refactored code
3. Utilize Static Code Analysis to identify vulnerabilities and weaknesses early in the development process
4. Utilize automated testing over manual

Go to Top of page

 Scope

These types of risks generally indicate scope will increase due to defects and insufficient testing of non-functional requirements.

Suggestions:

1. Move testing as far up into the development process as it makes sense in order to mitigate scope creep with leaked bugs
2. Utilize Static Code Analysis as part of the Contiuous Integration process in order to prevent scope creep from leaked vulnerabilities and weaknessed

Go to Top of page

 Team Satisfaction

Team satisfaction risks indicates potential issues with maintaining morale, cohesion among the team and with support teams, and personnel turnover. These effects can then easily negatively affect organizational culture and overall efficiency.

Suggestions:

1. Allow the team to self-organize and self-manage in order to deliver and deploy more optimally
2. Provide the teams with the tools they want and need to be more efficient
3. Remove non-valued added activities from the team
4. Allow the teams to automate everything they can in order to focus more time on adding value
5. Eliminate “checking-in” and “status” meetings in order to rebuild trust with the team(s)

Go to Top of page

 Technical

These type of risks occur when the Lifecycle Sleuth determines that elements of the technology stack are not current industry standards or are scalable. It is generally best to continually maintain the latest version of tools to ensure interoperability with other elements of the technical stack.

Suggestions:

1. Utilize industry favored solutions over custom-built ones for Continuous Integration and Continuous Delivery / Deployment
2. Maintain the latest version or near-latest version of tools
3. Maintain the latest version or near-latest version of software / testing frameworks
4. Favor scalable vice non-scalable platforms
5. Stop accommodating unsupported or deprecated tools and platforms
6. Take a program-level approach to acquiring, configuring, and using tools and frameworks

Go to Top of page

 Unforeseeable

It is a generally accepted belief in the project management world that all risks cannot be identified. While there is no quantifiable data to suggest the typical percentage of unforeseeable risks, research indicates that organizations generally accept 10% as the baseline.

Suggestions:

1. Collaborate with others to identify more quantifiable risks then those marked as Unforeseeable
2. Determine if the activities are value-added and, if not, eliminate them

Go to Top of page