February 28, 2017
Posted by tcagley under Change
| Tags: 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: (more…)
September 29, 2016
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. (more…)
September 27, 2016
Posted by tcagley under Risk
| Tags: Risk
, 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. (more…)
September 15, 2016
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. (more…)
September 13, 2016
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. (more…)
July 31, 2016
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. (more…)