Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Now on Spotify!

SPaMCAST 527, is our last podcast of 2018.  We say goodbye to 2018 by talking about user story maps.  User story maps are both versatile and an underused tool. Perhaps something that we can address in 2019?

We also have a visit from Susan Parente.  Susan brings her Not a Scrumdamentalist column to the cast to discuss agile risk management.  Risk management is a requirement for any form of work. Why do some in the agile community feel it is not needed?  

Re-Read Saturday News
We are re-reading Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along).  This week we move through three chapters. These three chapters continue to show the same pattern of abuse of the truth and employees that we have seen in other chapters. Arguably, conflating Theranos’s mission with a religion (chapter 14) might take the story to a new level of crazy but it is only that, a new level.

Week 10 – Chiat\Day, Going Live and Unicornhttps://bit.ly/2SrRpGv (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play MusicListen Now

The Software Process and Measurement Cast 440 features our essay on two storytelling techniques: premortems and business obituaries.  Almost all work that takes more than a few days is subject to risks that are not immediately obvious without some form of structured process to focus the team’s thought process. Teams often use storytelling techniques to generate a big picture/vision to guide a project or to help people frame their thoughts. A story provides a deeper and more nuanced connection between the team and information than most lists of PowerPoint bullets or a structured requirements documents. The same storytelling skill can be used as a risk management tool. Premortums and business obituaries are structured techniques for using storytelling for risk management.

Our second column is from Jeremy Berriault. Jeremy discusses the importance of conferences for learning new ideas and for networking.  Jeremy suggests that if you are have not learned new ways to test and you are testing the same way you were last year then you are falling behind. Jeremy  blogs at https://jberria.wordpress.com/  

Jon M Quigley brings his column, The Alpha and Omega of Product Development, to the Cast. In this installment, Jon discusses mental models and their impact on how you develop and deliver value.  One of the places you can find Jon is at Value Transformation LLC.

Re-Read Saturday News

Chapter 3 of Holacracy completes Part 1 by laying out the structure needed for an organization to be able to quickly and continuously evolve how authority is distributed.  An organization’s structure needs to be conducive to the processes needed to distribute authority.  This chapter provides an alternative to the classic pyramid structure of organization design which is typically out of date, irrelevant and difficult to change.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

A Call To Action

I need your help. I have observed that most podcasts and speakers at conferences over-represent people from Europe and North America.  I would like to work on changing that exposure. I would like to develop a feature featuring alternate software development voices beginning with Africa and Southeast Asia. If this feature works we will extend it to other areas.   If you can introduce me to practitioners that would be willing to share their observations (short interviews) I would be appreciative!

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with John Le Drew.  John and I discussed the concept of safety at work and how safety, or the lack of it, affects software teams.  John is the host of the Agile Path Podcast I recommend you check out his podcast but make sure you are back here for our interview next week!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

You can't capture risk with your camera. You need to have a conversation with a diverse group of stakeholders.

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…)

This is a risk I'm willing to take.

This is a risk I’m willing to take.

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:

Internal and External Risks

Incorporating the Idea of External Risk into Agile Efforts

Risk Tolerance (Current) 

******

 

A spider web has several external risks.

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…)

Evacuation Plan

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…)

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 344 features our conversation with Susan Parente.  We talked about Agile risk management. Risk is not always discussed in polite Agile circles however Susan suggests that if you do not have a plan to address risk you are asking for pain for yourself and everyone around you.

Susan’s Bio

Susan Parente is a Principal Consultant at S3 Technologies, LLC and an Associate Professor at Post University. She is an author, mentor and teacher focused on project and risk management. Her experience is augmented by her Masters in Engineering Management with a focus in Marketing of Technology from George Washington University, DC, along with a number of professional certifications. Ms. Parente has 16+ years’ experience leading software and business development projects in the private and public sectors, including a decade of experience implementing IT projects for the DoD.

Contact Data:

Email: parente@s3-tec.com

Phone: 203-307-5246

LinkedIn: https://www.linkedin.com/in/susanparente

Risk Management Resources: www.techriskmanager.com

Company website: www.s3-tec.com

Agile Risk Management LinkedIn Group:

https://www.linkedin.com/groups?mostRecent=&gid=4020498&trk=my_groups-tile-flipgrp

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next . . . The Mythical Man-Month Get a copy now and start reading! We will start in four weeks!

Upcoming Events

2015 ICEAA PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presentation is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our will essay on Cognitive Bias.  The core of software development, enhancements and maintenance is people. Knowledge of cognitive biases can help us understand and predict team behaviors. Will will also have the first installment Jeremy Berriault’s QA Corner.  QA Corner is all about testing.

 

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Risk management is like sorting out the cords.

Risk management is like sorting out the cords.

As we have noted, the difference between the classic and Agile approaches to risk management boils down to a few serious dichotomies. The first is that classic methods tend to be project-manager driven, while Agile processes involve and hold the entire team responsible. Second, Agile risk identification and management is built on the continuous re-planning process that is intrinsic to Agile rather than being event/review driven (e.g. phase gates or defined review cycles) which is more the norm in classic project management. All projects need to expend time and effort on dealing with regardless of the processes used to identify, monitor and manage risks. That time and effort means there will be less time to address the functionality requested by the product owner and product management. This leads project personnel to try to balance the effort they spend on the risk management process AND to only focus on the risks that really matter.

Lean risk management processes, such as the one we have described, focus on minimizing the effort needed to identify and manage risks by integrating risk management into other processes. Examples include using the definition of done to mitigate risk and the product backlog to document risks as user stories. Risk management does require specialized meetings and deliverables that increase the perceived overhead. Building risk management into day-to-day activities has secondary benefit of creating team level involvement which is useful for reinforcing the risk management process.

One of the common features of mature risk management processes (whether they reflect waterfall or Agile methods) is risk prioritization. We have explored several mechanisms to evaluate the probability the an risk will become an issue and the potential impact of the issue (Agile and Risk Management: Prioritization Techniques, Part 1 and Agile and Risk Management: Prioritization and Measurement Techniques, Part 2). In all cases the goal of the processes is to consistently prioritize risks so that teams and managers spend their time on the risks that really matter. I recently chatted with a project “risk manager” while waiting for a table at a restaurant. He suggested that he often sees projects without formal prioritization techniques spending precious time and effort on worrying about risks that they can’t influence or have a nearly zero chance of happening, but sound scary. Every erg of energy and every minute spent on risks that are not relevant is waste and provides fodder for those that see risk management as a waste of space.

One common complaint about risk management is that we can never anticipate everything; there are unknown unknowns. The conclusion some practitioners make is to abandon planning and to just stay vigilant. The argument is the effort for risk management is not worth the return. This approach might work, however I have not seen it work on any sizable project. Coupling a lean risk management process with Agile risk management maximizes the value from risk management. This morning while listening to the Gist podcast, Mike Pesca (the host) stated that worrying about the future is an important survival mechanism.  True but that survival mechanism doesn’t require a 100-page risk register that no one will ever look at to be effective.

You can't capture risk with your camera. You need to have a conversation with a diverse group of stakeholders.

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 always appropriate, however the typical meeting/events and the types of people to consider in the conversation need to be planned. The discovery process typically follows the requirements/user story discovery process outlined below.

  1. Carve out time when you are developing the backlog and ask as diverse a group as possible to identify the potential problems that could get in the away of delivering the value promised by the project. Prompt the group to consider business, technical, operational and organizational factors. Diversity is incredibly important to inject different perspectives, so that the team does not fall prey to only seeing the risks they expect (a form of cognitive bias).
  2. Form a small team (consider the Three Amigos) to interview stakeholders that were not part of the planning exercise. Explain the project and use the same category prompts to generate a risk discussion.
  3. Gather risk data though surveys when the program stakeholders are geographically diverse. (Note: I have only seen this used well in very large programs with professional market research staffs)
  4. Interview customers or potential customers. Customer interviews are not generally used as a standalone risk discovery tool, but rather as a tool to gather requirements/user stories. However, piggybacking a few questions to solicit potential risks is useful to add a diversity of thought to risk identification.
  5. Periodically ask about risks either as an agenda item or as a follow-on to standard meetings. For example, I have seen teams that have successfully added a five-minute follow on to the last daily stand-up of the week in order to consider risks. A quick risk recognition session can easily be added to other standard meeting many projects have. Other standard scrum meetings that can be used to identify risks include: demonstrations, retrospectives and sprint planning. Each of these meetings will provide a different perspective on the project and the team therefore could expose other potential risks.

The baseline answer to the question of how can I recognize and capture risks is by involving all of the projects stakeholders in a discussion of potential risks. The process of collaborative discussion will help increase diversity of thought, reducing (but NOT eliminating) the potential number of unknowns – unknowns that could impact the projects ability to deliver value.

Lava is not a risk category that is commonly encountered in software development.

Lava is not a risk category that is commonly encountered in software development.

I have recently been asking software development practitioners (including enhancements and maintenance) why they think that risk management is not consistently being practiced or practiced well. The group includes methodologists, developers, project and program managers, testers and test managers, operations personnel and executives. Very few have indicated that they thought that risk management was top of mind for any project, other than on an occasional event basis, or as one executive stated “when a project is asked publicly about risks.” The most common reasons why risk management is a second-class citizen include:

  1. There are too many other things to do directly related to delivering functionality. When asked why some project managers are perceived not to see the value in risk management, one respondent answered “They can’t when they’re working 12 hour days to keep the critical path moving.” This is a fairly common point of view. First, when you’re trying to do a twelve-hour job in an eight-hour day you will cut corners (add in multitasking and a disaster looms). Building risk management into the flow of work so that it isn’t a separate process with a separate risk plan and risk register should reduce the overhead generated when risk is an add-on to day-to-day project activities. A lean risk-management process will incorporate risk activities into team activities, but what needs to be addressed to mitigate the problem is the growing insistence on 50 – 60 hour workweeks.
  2. Risk management processes are driven by a need for an external certification. Many if not most of the people I talked with had a risk process, and if pressed could find a list of risks. However those processes and deliverables were developed for auditors and appraisers. In many cases the linkage between external frameworks, an organization’s expectations and policies (specifically for risk) have not been clearly linked to project outcomes. This is a common problem when teams are early in the adoption of Agile. Coaching is generally required to help teams develop the understanding that they will be able to deliver more value when then spend some time considering risks that could impact their ability to deliver. Coaches need to spend the time needed to help the team, organization or project manager to see the linkage between avoiding real issues and delivering value.
  3. Common risks are continually identified and nothing is done about those risks. Continually identifying environmental or long-term organization cultural issue that can’t be solved by team or the IT department is debilitating. In many cases what is being identified are issues that need to be mitigated or planned around. The example used above of project managers working 12-hour days to keep projects on track is not a risk, but an issue. Everyone involved needs to help address the problem the behavior will cause, unless the organizational culture can be changed and that is not something totally up to a team. Techniques such as sharing roles (team level self-organization) can be helpful to mitigate these types of issues. This is similar to issues seen in retrospectives that continually focus on issues that are not solvable (for example, a team that wants to work from home, but corporate policy forbids it due to security reasons). Over time a team will begin to feel helpless and will reject process. This, very simply, is a training and coaching problem.

One person noted that since risk management was not directly mentioned in the original book on Scrum, it must not be very important. I believe the comment was meant sarcastically, however it does make the point that risk management is only an issue in large projects or when project or program managers are involved. Risks and issues plague every human endeavor large or small, and must be addressed for effective and efficient delivery. Overburdened, multitasking teams need to be addressed as a rule. Incorporate a lean risk process into standard Agile or waterfall processes. Risks are just a different kind of user story or requirement that can be addressed in the common flow of work.