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. (more…)

risk-curve

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, and 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 seen on teams and in organizations. This leads us to the conclusion that we must talk about risk tolerance.   (more…)

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

The Software Process and Measurement Cast 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.
Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development.  Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems.  Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson.  Steve enjoys listening to technical podcasts, and SpamCast was one of the first and is a favorite!  Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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.

The Five Dysfunctions of a Team Cover

The “Book” during unboxing!

Today we begin the read of  The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing) as part of our Re-Read Saturday feature. This book uses a business novel approach to make his points. As I noted as we completed the re-read of XP Explained, Steve Adams suggested this book. This is a first read for me.  Please buy a copy and read along.  When we are done I will invite anyone that has contributed to the discussion to appear on the Software Process and Measurement Cast for a wrap-up discussion.

The book includes an introduction, two major sections, and 4 additional chapters. The two sections are titled:

  1.    The Fable.  The fable has five parts noted in the table of contents; however, it is made up of a large number of subsections.
  2.    The Model with three parts.

I suspect that we will read the book over 12 -13 weeks, each week representing a review of roughly 20 – 30 pages (depending on breaks in the book and the need to discuss the Lencioni’s ideas). Now without further ado… (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 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)

Measuring Risk Tolerance

******

 

Shadow

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective for making daily stand-ups work for distributed teams include: (more…)

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

The Software Process and Measurement Cast 411 includes four columns!  The first is our thoughts on servant leadership. A servant leader facilitates collaboration not only by creating a learning environment but also by helping the team to establish a vision and goals.  Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. Many of the links between servant leadership and Agile are because servant leadership enables several of the principles in the Agile Manifesto, but servant leadership doesn’t work in every scenario. This essay will explore the origins of servant leadership, its ties with Agile and when to apply a servant leadership approach.

Jon Quigley anchors the cast with the second installment in a three-part arc on requirements in his  “The Alpha-Omega of Product Development” column. This week Jon discusses managing requirements.

Gene Hughson brings his Form Follows Function blog to the Software Process and Measurement Cast.  In this visit, Gene discusses his recent blog entry titled, “Organizations as Systems – “Uneasy Lies the Head that Wears the Crown”.  Gene points out that software development organizations live in a complex world where single factor explanations are dangerous.

Kim Pries, the Software Sensi, brings a great discussion of the concept of craftsmanship in software development to the Cast.  Craftsmanship and quality are related, but craftsmanship is a more intimate and personal attribute. (more…)