Risks are indicators that something negative could occur with the solution being built because of specific activities, a set of activities, the manner in which certain activities are being executed, as well as a lack of expected activities. Currently, the Lifecycle Sleuth Waste, Opportunities, and Risk Engine (WORE) is able to identify 473 unique risks. The table below lists the waste categories in the Lifecycle Sleuth, a simple definition, as well as 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. |
|
![]() | 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. |
|
![]() | 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. |
|
![]() | Model | Risks of this kind indicate logical problems in a model that should be corrected before proceeding. |
|
![]() | 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. |
|
![]() | Policy / Regulatory | Indicates risks based on an activities, set of activities, or the lack of expected activities to meet policy and / or regulatory minimums. |
|
![]() | Quality | These types of risks most often indicate insufficient or outright lacking of testing earlier in the development and delivery cycle. |
|
![]() | Scope | Risks of this type indicate scope will likely increase due to defects and insufficient testing of non-functional requirements. |
|
![]() | 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. |
|
![]() | 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. |
|
![]() | 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:
- Identify non-value added activities and eliminate them
- Identify activities that can be reduced in scale and time and do so
- Automate manual activities
- Reduce defects with testing concentrated on eliminating them vice finding them (e.g. Unit Test & Integration Testing)
- Implement Continuous Integration (CI) in order to reduce integration complexity and have more “ready” code every day
- Utilize Static Code Analysis as part of the CI process in order to quicker identification and remediation of vulnerabilities and weaknesses
- Implement Continuous Delivery (CD) in order to ensure a consistent approach to delivering artifacts and testing them
- Implement Continuous Deployment or if by policy not able to, implement Single-Manual Click Deployment
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:
- Establish team working agreements for peer reviews and / or code reviews as close to development process as possible
- Establish retrospectives at the end of a major event (good or bad) in order to learn and improve
- Trust the processes by automating them including testing
- Break builds on testing deficiencies to build a culture that favors quality
- Eliminate “checking-in” or “status” meetings in order to build trust
- Eliminate manual stage gates to copy artifacts into follow-on environments
- Eliminate testing that just makes folks “feel good”
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
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
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:
- Emphasize on the need to prevent defects with unit testing and integration testing
- Establish team working agreements to have unit test code coverage of ~80% for new and refactored code
- Establish team working agreement to break builds when unit tests and integration tests fail in order to address problems earlier
- Utilize Static Code Analysis to identify vulnerabilities and weaknesses early in the development process
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:
- Document policy and regulatory needs for production releases for everyone involved in order to provide shared knowledge of these requirements
- Collaborate to determine ownership of policy and regulatory requirements
- Collaborate to identify and document policy and regulatory requirements so they can be incorporated into the Definition of Dones (Release, Capability, Feature, etc.)
- Collaborate to determine activities that can be automated to best ensure policy and regulatory requirements are met
Quality
Quality risks are most often triggered by expected testing activities and / or how they are being executed.
Suggestions:
- Emphasize on the need to prevent defects with unit testing and integration testing
- Establish team working agreements to have unit test code coverage of ~80% for new and refactored code
- Utilize Static Code Analysis to identify vulnerabilities and weaknesses early in the development process
- Utilize automated testing over manual
Scope
These types of risks generally indicate scope will increase due to defects and insufficient testing of non-functional requirements.
Suggestions:
- Move testing as far up into the development process as it makes sense in order to mitigate scope creep with leaked bugs
- Utilize Static Code Analysis as part of the Contiuous Integration process in order to prevent scope creep from leaked vulnerabilities and weaknessed
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:
- Allow the team to self-organize and self-manage in order to deliver and deploy more optimally
- Provide the teams with the tools they want and need to be more efficient
- Remove non-valued added activities from the team
- Allow the teams to automate everything they can in order to focus more time on adding value
- Eliminate “checking-in” and “status” meetings in order to rebuild trust with the team(s)
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 always best to continually maintain the latest version of tools to ensure interoperability with other elements of the technical stack.
Suggestions:
- Utilize industry favored solutions over custom-built ones for Continuous Integration and Continuous Delivery / Deployment
- Maintain the latest version or near-latest version of tools
- Maintain the latest version or near-latest version of software / testing frameworks
- Favor scalable vice non-scalable platforms
- Stop accommodating unsupported or deprecated tools and platforms
- Take a program-level approach to acquiring, configuring, and using tools and frameworks
Unforeseeable
Its 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:
- Collaborate with others to identify more quantifiable risks then those marked as Unforeseeable
- Determine if the activities are value-added and, if not, eliminate them
Consulting Services
disruptiveOps can support your organization with training, workshops, and consulting services to better understand how to identify waste, how to handle it, and continue to lean your processes. Please contact us or go to the services page of our website to learn more on how we can assist.
Access via RESTful Services
If your organization wishes to dynamically pull wastes outside of the Lifecycle Sleuth, we have the secured RESTful services to do so.