Last week I found myself pondering about Risk Management on Agile project environment. Google shows different opinions about that on the Internet.

I found people claiming that Risk Management is implicit in an Agile development environment and saying that it is not necessary to manage it explicitly. Those people claim that tracking risks "explicitly" in Agile is a waste. Team does that all the time with standups, review meetings etc. There is no need to track it explicitly. 

On the other side, a project is seldom contained in one sprint. So, others say that Risk Management is important and should be done explicitly.

I decided to ask Julia Checchia's opinion (http://linkd.in/qm3Pow)

Julia is the President of Project Management Institute (PMI) Sydney Chapter and has a very impressive resume. She is a lovely person and studies, teaches and lives project management with passion and energy.

Question 1

People have been saying that it is not necessary to manage risk explicitly on an Agile development environment. What is your opinion about Risk Management on Agile development environments?

Julia:

If anything, I believe risk management is even more important in agile. Risk management, ie. Identification of risks as well as opportunities is ever so important because given the 'small chunks' mentality of agile, a team may go substantially off track if the overall product goals and vision are not constantly revisited through a risk management review. 

Team meetings are meant to deal with issues, risk management is all about thinking of the impossible and assessing the impact on the overall business and project objectives.

Question 2

I understand and agree with you when you say that the Team may go off track if overall goals and vision are not constantly revisited. It is exactly the point of Agile. Between one "chunk" of work and another, the Team usually does a Sprint Review and (re)plan the next "chunk" of work based on the results of the previous one. Ideally, putting the team back on track.

Risk Management seems to be a good tool to be used on a Sprint Review meeting to detect when the Team is off track. But when is it too much? Vin, a reader of this blog, has a simplistic straight forward point of view: risk management should be applied "as the situation warrants". What that means?

As I have stated on another post, imprecision is a tool we use to reduce complexity. In the end of the day, what Agile does is using imprecision to reduce management complexity. In Agile, scope, schedule and roles became more fuzzy yet more tractable.  
Isn't it the same with Risk Management? Not explicitly identifying and managing risks seems to be a way to introduce imprecision and reduce complexity. Isn't Risk Management implicit when we revisit the goals and scope every sprint?

Another related question: I usually create schedules for my Agile projects, but I create them on another abstraction level, and I call them "roadmap" instead of "project schedule". Is there a way to do Risk Management in another abstraction level?

Julia:

Great long question! I would love to KISS the answer to be more “Agile”. Not sure if I managed. So, here we go...

Note that the basic principle of risk management is to assess:

1. enterprise environmental factors (organisation structure, market conditions, commercial databases, market trends, market innovation),
2. organisation process assets (outcome of other projects and organisation methodology),
3. resources,
4. project scope statement (vision, benefits, overall in scope, overall out of scope),
5. project management plan (the way we will deploy this project)   

to understand if there are negative influences that may hinder the completion of a project, project phase or “chunk”; or opportunities to accelerate the overall solution on a cost/time/quality perspective. 

I am not necessarily advocating a Risk Management Board with lots of heads thinking about what can go wrong, but a review that assess diligently whether there are opportunities or potential hindrances that can detract/attract the team from/to achieving the project objectives, product outcomes and respective business objectives. 

If the Sprint Review’s is all about the specific application scope then, the Sprint Review is not the most adequate forum for risk management. If however, the Sprint Review has a dedicated forum for assessment of the items ‘a’ to ‘e’ above, so, by all means, a Sprint Review is perfect to assess the risks. 

The matter of fact is,  if a project’s budget is a 100K, is developed by 3 -10 developers, is non-mission critical and will be used for entertainment for a non-demanding audience,  who would care about risks? On the other hands, try to put a project in production where the money of millions of people will be impacted by a resource badly trained who developed a piece of code which a newly acquired test manager assumed the developers knew what they were doing and let a “chunk” go into production without proper testing? 

And how about a newly available Microsoft component which was not available when you started your Agile project and when you were just about to start a new “chunk” development of a 99% similar Microsoft function which would take 1 month to deploy,  could be achieved with a Microsoft upgrade overnight? 

Type of risks above may express what Vin stated "as the situation warrants". 

In my opinion, imprecision of detailed scope of all the “chunks” before development takes place, can truly be a tool used to reduce management complexity. Nevertheless , when a “chunk” comes out of the production line, the “chunk” must be precise and its integration to the overall project must be precise or else you set a precedence for bad reputation, client and user dissatisfaction, low team morale, high operational incidents, high amount of problems to be managed in production, just to mention a few. 

I am not against “fuzzy” roles and responsibilities, ie when the developer is the business analyst who is the tester, the peer quality control, the implementer, the technician, the service desk, now... tell me is this realistic? Will “fuzzy” roles and responsibilities and imprecision increase accuracy, customer satisfaction, image and brand growth and team morale specially for mission critical applications? 

Sure you can create a risk “roadmap”, you can certainly create risk checklists (through domain expertise and lessons learned) with suggested risk response, with expected risk probability based on industry and technology knowledge, you can make risk management as simple or as complex as you need, it all depends on who you are delivering a project to. If it is mission critical, if the brand of your organisation is important, if your business growth is important, if customer satisfaction is important, if cost containment is important, assess your risks and opportunities and capitalize on your findings.   

I thought the link below was a very good link on agile risk management:

 http://bit.ly/oKEDh4

Question 3:

 Julia, thank you very much for your contribution! Your insights are valuable for Agile community. Do you have any final words or suggest any complementary reading?

Julia:

Rodrigo thank you so much for the attention, just some food for thought: everything old become new, before processes and methodologies were put in place there was agility because organizations relied on individual skills, there was little documentation, and risks were rather ignored because of sheer ignorance. We do not want to use Agile wrapped in ignorance, we want to use Agile for quicker, attainable and accurate immediate results. Brushing off risks in Agile may jeopardize the integration of all the components of the end-to-end solution.

Some time ago, I was having some beer with a friend of mine when she asked me: "What do you think about Astrology?". I said: "Well, as a scientist, I do believe that the influence of any celestial body on me is directly proportional to the product of its mass and inversely proportional to the square of its distance." She smiled at me: "If you do not know what Astrology is, how can you say that it is not good?".I had to agree: "Ok.. You win. Give me the number of a professional Astrologer".

One month later, I went to the Astrologer - yes, I had to wait one month for an appointment! The Astrologer was a nice and charismatic old lady. I immediately realized that she was "reading" me. Since the very first moment, when she opened the door, she was observing my body language, my vocabulary, my expressions, everything. She then started a psychic conversation about my day of birth, how it is related to planets and start, etc. This conversation was kind of amusing. She was very funny and make me relax and open myself, talk about my preferences and behavior. After half an hour of conversation, she started talking about myself and my future. At that moment I understood what it was all about. She classified me. She had a methodology to analyze me and find my psychological archetype. Knowing that, she knew a great deal about me and everything she said made sense.

I then realized that Astrology is an ancestral psychology. Based on centuries of observations of the human behavior, Astrologers found patterns and defined archetypes. As it was before the age of lights, some mysticism was used to explain the unknown. So the signs of Zodiac and their infinite combinations are nothing more than tools to simplify the complexity of the human nature and define clusters.A contemporary approach for what the astrologer did for me is the the Myers-Briggs Type Indicator (MBTI). As Romans used to say... Mutatus mutandi, it is the same: catalogue, describe and classify clusters and archetypes.

Well, what it is has to do with technology? Everything. Software is model. Astrology shows us how powerful imprecision is to reduce complexity. Even with lack of strong scientific methods and statistical tools, Astrologers did very well for centuries with Astral Maps and the hole Zodiac thing. 

Most of the decision problems we know are computationally intractable if we try the brute force. It is frustrating when you spend hours to have an exact and deterministic model of a problem to then figure out that it is not computationally tractable. In most cases, the pragmatic solution lies on the use of heuristics, imprecision an uncertainty. Just two examples: Approximate Dynamic Programming (ADP) and Fuzzy Logic. ADP allows us to address problems with far more complexity than are traditionally handled using tools such as linear programming. Fuzzy logic allows us to represent imprecise relations and do approximated reasoning.

If you ask me if I prefer a MBTI analysis or an Astral Map, I would say: "well, it depends on the Astrologer." The same on software...  What is the best modeling approach for a given problem? Well, it depends on the engineer and the user/business environment. No problem exists isolated from the real world. In one way or another, people are already solving it on their business. Humans are smart, we naturally and instinctively use imprecision and uncertainty to reduce complexity and cut corners. So why reinvent the wheel? Instead of remodeling it from the scratch, my advice is: explore the existing solution. Extract the heuristics and simplifications already used using tools like Fuzzy Logic and ADP. Find fast and first a good enough solution. Only after that try to improve in interactions, following Agile philosophy. 

To find uncertain and imprecise yet good solutions for complex problems it is necessary to be open minded. It is necessary to listen people and be opened to realize that the System Operator might have found a solution not yet found on PhD level books. It is just a matter of interpreting his myths and translating them to software. Fuzzy Logic, Rule Based Expert Systems, Neural Nets, ADP, and others, are tools that can be used for this translation and achieve a less complex and more tractable model.

Summarizing, as Engineer, I try to be a good "Fuzzy-Stochastic-Neural-Heuristic-Astrologer". :-)

One day a Java class asked an elder Software Engineer: "I keep hearing people talk about this thing called Software Architecture. Just what is Software Architecture?". The Software Engineer patiently answered: "Software Architecture is what surrounds you". The innocent Java class then asked: "but why can't I see it? Is it an UML diagram?"The Software Engineer smiled and said: "UML diagram is just a projection. Just one perspective. Software Architecture is within you and all around you. You were born in the Software Architecture. It envelops you just like your interfaces do."

Confucius said, "fish forget that they live in lakes and rivers;" Programmers tend to incarnate their own code. Doing that, they cannot see the Software Architecture, yet they do know what it is. (well, sometimes don't).

If you are a developer, try to keep the big picture in mind, even when you focus the details. 

Don't forget that your software lives in a sea of Zen.

*freely adapted from "Zen Speaks"