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. (more…)
September 29, 2016
September 22, 2016
Leave a Comment
A risk is the potential or exposure to danger, harm or loss. The concept of risk is understandable to everyone involved in delivering work, at least at a basic level. We understand that “stuff” can happen when we least expect it to happen, in a project or in our individual lives. The question is whether any specific risk or the accumulation of risks is worth taking action to avoid. Which risks are perceived to be so daunting that they need to be actively avoided is based on personal and organizational perspectives and biases. The technical term for this behavior is risk tolerance. In response to Internal and External Risk, Matt Williams commented:
“An important step that I think often gets overlooked is the act of defining a risk tolerance.While many teams (or organizations) may have an intuitive sense of their risk tolerance, I think it’s helpful to have an explicit, conscious discussion about risk tolerance.”
We can define risk tolerance in simple terms as how much value are we willing to lose if a risk materializes. The impact of a risk materializing and becoming an issue can range from rework, a reduction in returns, shifting positive perceptions or a compliance failure. A reflection of risk tolerance, in the financial markets, is the difference between the rates of return for a financial instrument (e.g. stocks, bonds, and others) and another financial instrument (such as a treasury bond). In finance the higher the risk the higher the return is required to balance.
If risk tolerance is important for the governance of software development and maintenance projects, we need a mechanism to define tolerable and intolerable risks before we decide how to ROAM risks. Assessing risk tolerance is an evaluation of the willingness to take on risks and how much “exposure” from threats from outside the company are acceptable.
In a further comment Mr. Williams went on:
“I think risk tolerance is very context-specific. It depends in part on the organization – its size, culture, mission, etc. – in part on the project and its specific nature, and in part on the nature of the risk itself.”
Every person and organization has a different level of risk tolerance. We can visualize risk tolerance in a chart as a curve. Risk tolerance is a balance between probability the probability a risk occurs and the impact that will be realized if it does occur. In most software development and maintenance efforts defining the risk/tolerance curve is an implicit rather than explicit act. The issue is that a team’s or organization’s level of risk tolerance will cause different behaviors. Risk avoiders, teams or organizations that fear the impact of risks, will tend to do more research or analysis before committing to a direction. Risk takers tend to try approaches and then pivot if needed.
Risk tolerance affects how everyone in an organization behaves. Rarely, however, does everyone in an organization have the same tolerance towards risk. Defining or at least developing an understanding of a team’s risk tolerance isn’t merely an academic discussion. Differences in risk tolerance can generate tensions and risks of its own, therefore at the very least teams need in the words of Mr. Williams, “have an explicit, conscious discussion.”
Current Risk Arc:
Risk Tolerance (Current)
September 15, 2016
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. (more…)
October 18, 2014
Hand Drawn Chart Saturday
I once asked the question, “Has the adoption of Agile techniques magically erased risk from software projects?” The obvious answer is no, however Agile has provided a framework and tools to reduce the overall level of performance variance. Even if we can reduce risk by damping the variance driven by complexity, the size of the work, process discipline and people, we still need to “ROAM” the remaining risks. ROAM is a model that helps teams identify risks. Applying the model, a team would review each risk and classify then as:
- Resolved, the risk has been answered and avoided or eliminated.
- Owned, someone has accepted the responsibility for doing something about the risk.
- Accepted, the risk has been understood and the team has agreed that nothing will be done about it.
- Mitigated, something has been done so that the probability or potential impact is reduced.
When we consider any risk we need to recognize the two attributes: impact and probability. Impact is what will happen if the risk becomes something tangible. Impacts are typically monetized or stated as the amount of effort needed to correct the problem if it occurs. The size of the impact can vary depending on when the risk occurs. For example, if we suddenly decide that the system architecture will not scale to the level required during sprint 19, the cost in rework would be higher than if that fact were discovered in sprint 2. Probability is the likelihood a risk will become an issue. In a similar manner to impact, probability varies over time.
We defined risk as “any uncertain event that can have an impact on the success of a project.” Does using Agile change our need to recognize and mitigate risk? No, but instead of a classic risk management plan and a risk log, a more Agile approach to risk management might be generating additional user stories. While Agile techniques reduce some forms of risk we still need to be vigilant. Adding risks to the project or program backlog will help ensure there is less chance of variability and surprises.
October 17, 2014
Have ever heard the saying, “software development would be easy if it weren’t for the people”? People are one of the factors that cause variability in the performance of projects and releases (other factors also include complexity, the size of the work, and process discipline.) There are three mechanisms built into most Agile frameworks to address an acceptance of the idea that people can be chaotic by nature and therefore dampen variability.
- Team size, constitution and consistency are attributes that most Agile frameworks have used to enhance productivity and effectiveness that also reduce the natural variability generated when people work together.
- The common Agile team size of 7 ± 2 is small enough that team members can establish and nurture personal relationships to ensure effective communication.
- Agile teams are typically cross-functional and include a Scrum master/coach and the product owner. The composition of the team fosters self-reliance and the ability to self-organize, again reducing variability.
- Long lived teams tend to establish strong bonds that foster good communication and behaviors such as swarming. Swarming is a behavior in which team members rally to a task that is in trouble so that team as a whole can meet its goal, which reduces overall variability in performance.
- Peer reviews of all types have been a standard tool to improve quality and consistency of work products for decades. Peer reviews are a mechanism to remove defects from code or other work product before they are integrated into larger work products. The problem is that having someone else look at something you created and criticize it is grating. Extreme programing took classic peer reviews a step further and put two people together at one keyboard, one typing and the other providing running commentary (a colloquial description of pair programing). Demonstrations are a variant of peer reviews. Removing defects earlier in the development process through observation and discussion reduces variability and therefore the risk of not delivering value.
- Daily stand ups and other rituals are the outward markers of Agile techniques. Iteration/sprint planning keeps teams focused on what they need to do in the short-term future and then re-plans when that time frame is over. Daily stand-ups provide a platform for the team to sync up on a daily basis to reduce the variance that can creep in when plans diverge. Demonstrations show project stakeholders how the team is solving their business problems and solicit feedback to keep the team on track. All of these rituals reduce potential variability that can be introduced by people acting alone rather than as a team with a common goal.
In information technology projects of all types, people transform ideas and concepts into business value. In software development and maintenance, the tools and techniques might vary but, at its core, software-centric projects are social enterprises. Get any group of people together to achieve a goal is a somewhat chaotic process. Agile techniques and frameworks have been structured to help individuals to increase alignment and to act together as a team to deliver business value.
October 16, 2014
There are many factors that cause variability in the performance of projects and releases, including complexity, the size of the work, people and process discipline. Consistency and predictability are difficult when the process is being made up on the spot. Agile has come to reflect (at least in practice) a wide range of values ranging from faster delivery to more structured frameworks such as Scrum, Extreme Programing and Scale Agile Framework Enterprise. Lack of at least some structure nearly always increases the variability in delivery and therefore the risk to the organization.
I recently received the following note from a reader (and listener to the podcast) who will remain nameless (all names redacted at the request of the reader).
“All of the development is outsourced to a company with many off-shore and a few on-site resources.
The development agency has, somehow, sold the business on the idea that because they are “Agile”, their ability to dynamically/quickly react and implement requires a lack of formal “accounting.” The CFO here wants to move away from vague generic invoices because he feels (rightly so) that the agency interprets the relationship as having carte blanche to work on anything and everything ever scratched out on a cocktail napkin without proper project charters, buy-in, and SOW.”
This observation reflects a risk to the organization of an ill-defined process in terms the value that get delivered to the business, financial risk and from the risk to customer satisfaction. Repeatability and consistency of process are not a dirty words.
Scrum and other Agile frameworks are light-weight empirical models. At their most basic levels they summarized as:
- Agree upon what your are going to do (build a backlog),
- Plan work directly ahead (sprint/iteration planning),
- Build a little bit while interacting with the customer (short time box development),
- Review what has been done with the stakeholders (demonstration),
- Make corrections to the process (retrospective),
- Repeat as needed until the goals of the work are met.
Deming would have recognized the embedded plan-do-check-act cycle. There is nothing ad-hoc about the frame even though it is not overly prescriptive.
I recently toured a research facility for a major snack manufacturer. The people in the labs were busy dreaming up the next big snack food. Personnel were involved in both “pure” and applied research, both highly creative endeavors. When I asked about the process they were using what was described was something similar to Scrum. Creatively being pursued within a framework to reduce risk.
Ad-hoc software development and maintenance was never in style. In today’s business environment where software in an integral the delivery of value, just winging the process of development increases risk of an already somewhat risky proposition.
October 15, 2014
Risk is reflection of possibilities, stuff that could happen if the stars align. Therefore projects are highly influenced by variability. There are many factors that influence variability including complexity, process discipline, people and the size of the work. The impact of the size can be felt in two separate but equally important manners. The first is the size of the overall project and second is the size any particular unit of work.
Overall project size influences variability by increasing the sheer number of moving parts that have to relate to each other. As an example, the assembly of an automobile is a large endeavor and is the culmination of a number of relatively large subprojects. Any significant variance in how the subprojects are assembled along the path of building the automobile will cause problems in the final deliverable. Large software projects require extra coordination, testing, integration to ensure that all of the pieces fit together, deliver the functionality customers and stakeholders expect and act properly. All of these extra steps increase the possibility of variance.
Similarly large pieces of work, user stories in Agile, cause similar problems as noted for large projects, but at the team level. For example, when any piece of work enters a sprint the first step in the process of transforming that story into value is planning. Large pieces of work are more difficult to plan, if for no other reason that they take longer to break down into tasks increasing the likelihood that something will not be considered generating a “gotcha” later in the sprint.
Whether at a project or sprint level, smaller is generally simpler, and simpler generates less variability. There are a number of techniques for managing size.
- Short, complete sprints or iterations. The impact of time boxing on reducing project size has been discussed and understood in mainstream since the 1990’s (see Hammer and Champy, Reengineering the Corporation). Breaking a project into smaller parts reduces the overhead of coordination and provides faster feedback and more synchronization points, which reduces the variability. Duration of a sprint acts as constraint to the amount of work that can be taken and into a sprint and reasonably be completed.
- Team sizes of 5 to 9 are large enough to tackle real work while maintaining the stabile team relationships needed to coordinate the development and integration of functionality that can potentially be shipped at the end of each sprint. Team size constrains the amount of work that can enter a sprint and be completed.
- Splitting user stories is a mechanism to reduce the size of a specific piece of work so that it can be complete faster with fewer potential complications that cause variability. The process of splitting user stories breaks stories down into smaller independent pieces (INVEST) that be developed and tested faster. Smaller stories are less likely to block the entire team if anything goes wrong. This reduces variability and generates feedback more quickly, thereby reducing the potential for large batches of rework if the solution does not meet stakeholder needs. Small stories increases flow through the development processes reducing variability.
I learned many years ago that supersizing fries at the local fast food establishment was a bad idea in that it increased the variability in my caloric intake (and waistline). Similarly, large projects are subject to increased variability. There are just too many moving parts, which leads to variability and risk. Large user stories have exactly the same issues as large project just on a smaller scale. Agile techniques of short sprints and small team size provide constraints so that teams can control the size of work they are considering at any point in time. Teams need to take the additional step of breaking down stories into smaller pieces to continue to minimize the potential impact of variability.