Agile Management | NOOP.NL

What If... People Focused on Opportunities?

I am renting out my house in Rotterdam to strangers. I rarely make use of it anyway. (And I have another home in Brussels too.) So why not let someone else enjoy my apartment?

Interestingly, this decision has led to some concerns from my friends:

1. What if those strangers steal your stuff?
2. What if they make copies of your keys?
3. What if they use your phone to make expensive calls?
4. What if they get access to your computer?
5. What if… what if… what if…

Sure, these are good questions.

But I find it strange that I never got questions such as these:

1. What if those strangers become good friends?
2. What if they fix the broken lamps?
3. What if they present an unexpected business opportunity?
4. What if they keep the house safe from burglars?
5. What if… what if… what if…

These are good questions too. But nobody considers them. Except me.

Here’s a fragment of my book, relating to this issue:

People often favor risk avoidance over opportunity seeking. They look at uncertainty as something that is more likely to have a negative outcome than a positive one. (Or they estimate the cost of potential problems to be greater than the benefit of positive outcomes.)

A good example is the often cited “threat” of non-native species being transported by humans from one ecosystem to another. Many environmentalists are actively trying to address this “threat.” But research has shown that only in a few percent of the cases non-native species had a significant and bad effect on existing ecosystems. In most other cases, the effects of “alien” species on native ecosystems were neutral, or even positive. [Davis, Mark. “Living with aliens.” NewScientist. 26 September 2009.]

I seem to be different from most people. I usually focus on opportunities first, and risks later. When I invite non-native entities into my ecosystem, my first thoughts are not about all kinds of dangers. Instead, I imagine interesting opportunities. And for good reasons.

For example, within an hour after I invited my first guest into my house, it turns out he might have a new employment opportunity for my housekeeper.

Somehow, I was not surprised.

(Jurgen Appelo is author of Management 3.0, a best-selling management book for Agile developers. It has a picture of a monster in it.)

Managing Risk vs. Managing Yourself

I have returned from Sweden as happy guy, though the mosquitoes tried to make my vacation miserable. They were successful in leaving their traces all over my body, and even pricked me in areas that are rarely exposed to daylight. But the mosquitoes couldn’t destroy the joy I felt, as Sweden is one of the best places to live on earth.

But Sweden cannot take all the credits for our wonderful vacation. A little risk management helped as well…

Three bottles of DEET and Autan helped us to reduce the number of troublesome bugs to a tolerable level.
Our big rented car (Volvo V70) helped us to transport many bags full of camping gear over long distances (3,500 kms).
Special clothing for hiking helped us in handling sweat, weather conditions, and various natural circumstances.
Several guides had warned us in advance for suicidal reindeer wandering carelessly on the roads.
And with all kinds of tools, from Swiss knives to flashlights, we were able to sustain ourselves in the wild.

Risk management is about the known unknowns. About things you know that might happen, which enables you to plan accordingly. Risk management is taking care of eventualities.

But things can turn out very differently when dealing with unknown unknowns. They are the things that you don’t know that might happen. You cannot plan for what you don’t know.

I once had two flat tires in the Nevada desert.
We once had a broken gear box in the middle of South Africa.
We once had all our baggage stolen from our car in Spain.
I once experienced a bout of diarrhea while hiking in Patagonia.
And we were once extorted by the police in Brazil.

These are things most people don’t plan for. They are the unknown unknowns. When you don’t even realize the things that could happen to you, you cannot plan for it either.

You can only manage the unknown by managing yourself…

• Don’t panic. Panic doesn’t get you out of a desert. Thinking does.
• Be flexible. A Spanish thief is now wearing your Eeyore shorts. So what?
• Be creative. There are plenty of ways to wipe your behind on a hiking trail.
• Don’t give up. At some point in the future, the problem will be behind you. Hold on to that thought.

And have a good laugh when the troubles are behind you.

Like I did.

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
The Three Types of Change
Your Project Will Suffer from Power Laws
Agile is NOT a Risk Management Strategy

Programming and Project Management Styles Resonant (guest post)

This is a guest post by Pradeep Bhanot. Pradeep is the Product Marketing Director for IT Governance solutions for EMEA at CA. He is based in England after a 16 year spell in California’s Silicon Valley. Bhanot is a U.S. patent holder and earned a bachelor's degree in Computer Science from Greenwich University.

My work in change management has taught me that change is inevitable and should be embraced, not feared. Project management needs the formality of traditional methods to satisfy the need for rigor, auditability, accountability and control. Project management practices encourage project reviews after the project is live to gather learnings that the PMO can use to refine and institutionalize good practices in future projects. Changes within a project that impact scope, schedule and cost, are usually treated as negative exceptions.

Project management can take a leaf out of the software development world, which parallels PPM by implementing a formal Software Development Life Cycle (SDLC) process to ensure quality and accountability, but has been far more open to make change management the norm and channel it into a constructive force.

Decades ago, when I first started programming, I would first create a shell using a boilerplate for the main program and exception handling. I would then outline all the required functions that would need to be called. This parallels the outline of a project plan that forms the natural sync or review points or gates. Next, I would add all the comments describing the main body and functions, which would ease maintenance, QA and provide the basis for demonstrating adherence to the requirements document (if any). Changes to requirements would also be documented in the comments. Today, these would also be captured in an integrated or external requirements system. In the case of CA Clarity PPM, the requirements planning feature is part of the project management function. These high level specifications form the basis of the design and can be used by QA, project management and documentation writers to gain a common view of the intended functionality.

The interesting part for me was coding the functions taking a stepwise-refinement approach (similar to the Kaizen or “continuous refinement” element in Lean approaches that encourage “change for good”). This is similar to today’s iterative methods, such as Agile approaches that enable the work to be scaled up to tight development teams to harness the energy of many eyes and brains to build a quality deliverable in a short space of time.

The cultural change project management is going through now is making change management a norm, rather than an exception, and adopting agile approaches to improve planning for the fast execution of sub-projects, while maintain quality and ensuring customer acceptance. This recognizes that requirements change and fosters closer collaboration between the build team and the customer as they refine requirements and the shape the deliverables together.

The result is rapid delivery of projects that meet the sponsor’s requirements, increasing success rates.

(images by mshades)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
The Three Types of Change
Creativity as the Root of Software Development
Change is the Only Constant

Commit to Sprint Planning or Definition of Done, Not Both

I'm having trouble with people's use of the term commitment.

In Scrum and other agile processes, the term commitment-based sprint planning is used to indicate that a development team should promise to deliver the set of features as agreed upon in the planning meeting. In fact, the team should try and do everything they can to deliver the features at the end of the sprint.

But what if things go wrong?

What if a team member falls ill? What if there's a 1-day power failure?

What if the technical platform turns out to have bugs the size of Gregor Samsa?

Murphy's Law dictates that there's always something going wrong, in every sprint. Most often the problems are small and neat, but sometimes they are big and smelly. This cannot be prevented. Many people try to estimate the amount of uncertainty per sprint, but the power law in our projects dictates that we cannot estimate the size of trouble. So, whatever the size of the problem, a team simply has to deal with it when it hits them in the face and craps all over their task board.

The team has three choices:

1. Work more hours to compensate for the setback, and still deliver all features;
2. Cut corners in quality, which means breaking the Definition of Done;
3. Skipping some of the features, which means not adhering to the sprint planning.

It appears the team is faced with a small version of the project management triangle, or the triangle of constraints. Which isn't surprising, because a sprint is nothing more than a very small project.

Option 1 conflicts with the Sustainable Pace and 40-Hour Week practices. All available research shows that management and teams should commit themselves to a sustainable pace (which is any amount of hours a team feels comfortable with).

Option 2 conflicts with the goal of delivering a quality product. In a professional agile environment, the Definition of Done should not be ignored, unless the team unanimously agrees to incur technical debt that should be resolved in later sprints.

Option 3 conflicts with commitment-based sprint planning. If you decide it's ok to skip features then you're sending people the message that it's ok to break commitment. And commitment-based sprint planning loses its value.

So, will you break your commitment to the sustainable pace? Or to the Definition of Done? Or to commitment-based sprint planning? Pick one!

If your best option is to break some commitment when things go wrong, then you shouldn't be calling it commitment in the first place!

You are sending the wrong message when you decide to break any commitment. You're showing people that it's ok not to do what you promised. If you break commitment to one of the three options, then people might feel free to break the others too!

Commitment
Interaction dominated by obligations. These obligations may be mutual, or self-imposed, or explicitly stated, or may not. Distinction is often made between commitment as a member of an organization (such as a sporting team, a religion, or as an employee), and a personal commitment, which is often a pledge or promise to ones' self for personal growth. (Wikipedia)

Don't make promise you may not keep...

There should only be a real commitment for the things that are absolutely essential to make the project survive in a troublesome environment. For some projects (like the one I'm working on now) this means commitment to release a high-quality product some time in the future. This translates to my commitment to the Definition of Done, but I won't commit to individual sprints plannings. For other projects it can mean commitment to release a feature-complete product at a certain deadline, which translates to a team's commitment to delivering certain sprint items, but then they shouldn't commit to the Definition of Done.

And if both are unacceptable to you (when you need commitment to both quality and features), then you must explicitly decide not to commit to a sustainable pace.

Unfortunately, I have no extra-sensory perception. I cannot tell you what you should commit to. It depends on the project, and your decision may change with every sprint.

But I believe that, whether explicitly or implicitly, every week you should choose not to commit to either sustainable pace or the Definition of Done or the sprint planning. You cannot commit to all. And my suggestion would be to choose explicitly at the start of each sprint, and write your decision on your task board! Make the choice together. Communicate your decisions. And prevent any wrong assumptions.

And choose wisely.

(images by littledan77 and discoodoni)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
About Project Success and Failure
You Are a Gardener (Oh, and Me Too)
How to Annoy Your Boss (14 Real-Life Tips)

Planning for Feature-Complete Deadlines

Next week I will be on vacation in Sweden. I am really looking forward to that. If the northern part of Sweden allows it, you can expect tweets from me while driving in our huge rented Volvo, or while attempting to put up our tent, cursing and swearing. Or while swimming in one of Sweden's many lakes, au naturel, scaring away all the fish. Except the blind ones.

But first I have to do some vacation planning and risk management.

My plane leaves at 6:55 in the morning next Wednesday. How late do I need to get up?

I know that the time between getting out of bed and entering the plane is about two hours when everything goes as planned. So, will I get up at 4:55? Of course not! Things never go as planned, do they? I know (from personal experience) that halfway to the airport I might have to return home to fetch my passport. Or my car (and me) might suffer a flat tire. Or two. Or there's going to be a huge traffic jam. Or at the check-in desk there's going to be a family before me with three children, six suitcases, 22 items of hand luggage, a doggy house, and a refrigerator. (And they will want to negotiate the charge on surplus baggage too.)

Planning to catch a plane is a perfect example of risk management for contained change: problems are expected, but they usually fall within a range you can still make an estimate of. (I wrote about this in my post The Three Types of Change.) Using experience I can make a probabilistic forecast of the time required to catch the plane. It will take two hours at the least to be there on time. But when Murphy's Law hits me (and it usually does in some way) it could be anywhere up to four hours.

So, what time will I get up?

Exactly... 2:55

Maybe 3:25 (when I'm feeling bold and confident)

Planning to catch a plane is like planning for a feature-complete deadline. Unless I'm flying with Air Force One, the plane is not going to wait for me. And when I arrive at the gate it has to be with a minimum set of requirements: passport, ticket, baggage, etc.

It amazes me how few customers and project managers apply similar probabilistic risk management when planning for a feature-complete deadline. They get an estimate from a development team that says "We could do this project in X weeks when everything goes as planned". And then the team, project manager, and customer negotiate a project deadline at X weeks + 1 day.

Why? It doesn't make any sense.

I don't set my alarm clock at 4:55 either, do I? People would call me a fool if I did that.

Yes but, I hear you say, we are going to do the project with Scrum! So we have a potentially shippable product every sprint, and we could skip the least important features when we're running out of time. And then I would reply: of course you must do that! But Scrum and agile won't help you with a feature-complete deadline...

When I'm running out of time while trying to catch a plane, skipping the parking of my car and simply leaving it at the terminal entrance is not an option. And neither is throwing away my suitcase so I can skip the check-in desk, nor running past the security check, or sneaking past the line for customs. You are required to do all of that and catch the plane too! You could skip breakfast and coffee when things go wrong, but that's about all the leeway you have.

Many product releases must contain some minimal set of features, or otherwise their release won't have any value at all. In such cases project managers and customers must apply probabilistic risk management. Agile planning cannot save their behinds by skipping features. In such cases there's one-and-only-one risk management approach:

1. Make an estimate for the minimal set of features (the Must-Haves);
2. Pad this estimate using your experience (which could mean: double it or even triple it);
3. Use that new number for your release planning towards the deadline.

If you do this well, the slack you've built in should give you plenty of time for an agile approach towards all your Should-Haves and Could-Haves, like breakfast, coffee, and tax-free shopping.

The amount of Must-Haves can vary wildly per project. Some don't even have any. I can apply agile planning to my whole trip through Sweden, because all the interesting things we intend to do are Should-Haves and Could-Haves. Except, of course, the parts where I go swimming in the lakes. After all, without the swimming there would be no point going to Sweden.

(Note: during my vacation I have some slots available on my blog for guest posts. Contact me if you're interested. Your guest post should be related to managing software development, or swimming in Swedish lakes, and I'd like to receive the final version on Tuesday, with a first draft on Sunday or Monday.)

(image by Per Ola Wiberg)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
The Three Types of Change
Agile is NOT a Risk Management Strategy
Agile Is a Risk Management Strategy

The Three Types of Change

Last week I moaned about power laws, and how they make our lives miserable. The realization that power laws are disturbing our work gave us a bleak and depressing perspective on projects. My post might have caused some distress among readers. Maybe some project managers have been having sleepless nights ever since that post.

I hope not. Because things are not all that bad.

But before I relieve you of the stress, I'm going to tell you about the three types of change processes. They have been described by Ralph Stacey, a British researcher into complexity and organizations, in his book The Chaos Frontier:

Closed change
Unambiguous problems and clear connections between cause and effect are the distinguishing characteristics of closed change. People are able to accurately forecast the effects that closed changes have on a system. It is possible to control such changes in a formal and analytical way. Examples of closed change might be: changing the customer's logo in an application, watching 188 episodes of South Park, and shopping for a loaf of bread. With closed change a task has a known purpose, including any alternative ways of achieving that purpose, with a corresponding effort that can be correctly estimated or calculated.

Contained change
Management of contained change takes the form of probabilistic forecasts. In this case the effect of one particular change cannot be determined accurately, but similar historical tasks and events in the past provide valuable empirical data on the probability distribution. Examples of contained change could be: changing the style and theme in an application (more complex than just a logo, but still something we have experience with), painting an entire house (if you've done such things before), and shopping for your 40th birthday party (which, in my case, is next Monday. Remember that!) With contained change the purpose of the task is still known, though the estimate of effort is somewhat blurry due to many possible changes. However, the variability of those changes is restricted to a range we understand well.

Open-ended change
For open-ended situations control is impossible. The changes themselves and their consequences are unknown to us, so we cannot compare probabilities to similar historical tasks and events. There can be many reasons. We're unfamiliar with the problem. The purpose of the task may be vague. The people involved may not be not fully committed. Or the information available is insufficient or subjective. In short, the situation is unique and/or unclear, and it defies both analytical and empirical forecasts. Examples of open-ended change might be: migrating an existing web design to a new and unproven technological platform, painting the entire neighborhood (if you've never done such a thing before), and building a bridge from Denmark to Sweden.

Let me give you a personal example:

Two weeks ago I cooked a dish of which the recipe says it takes only 17 minutes to make (which, being a man alone in the house, was of course the reason I selected it in the first place). The first time I made it I was surprised that the dish took me exactly one hour to make. Either I'm a very slow cook, or the recipe was lying. (I'm settling for the latter option.) Needless to say, that first time my cooking efforts were faced with open-ended change. Everything took longer than I had anticipated. And the recipe was silent about some essential tasks. Fortunately, the result was delicious...

Today I made that same dish again. However, due to my critical spouse being in the house, I changed some of the ingredients. I swapped the canned vegetables for fresh ones that I had to cook myself. I knew that cooking these vegetables would take about ten minutes, so I added that time to my expected delivery time of one hour. It is a fine example of contained change. Both numbers (one hour plus ten minutes) were derived from earlier experiences. Short from an exploding kitchen the impact of all expected changes could simply be estimated using empirical data.

By repeatedly cooking (more or less) the same dish I am able to reduce the estimation problem from open-ended change to contained change. However, it will never be a closed change problem, as it is impossible to calculate how long it takes to cook a dish. Empirical data is all we have.

The three types of change (closed change, contained change, and open-ended change) each require a different approach to estimation. They are not three discrete categories, but rather a scale from closed to open-ended. Depending on the information available, problems can move in either direction:

Problem size, complexity, and uncertainty will push a problem to the right side of the scale. Reliable information and communication can pull a problem to the left side. And the location on the scale will determine the best approach in estimating time and effort.

Another time we will talk about how to tackle open-ended problems suffering from power law disturbances.

Until then, sleep well!

(Note: some of this information was borrowed from the following scientific article: Systemic planning: Dealing with complexity by a wider approach to planning, by Steen Leleur)

(image by nate steiner)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Your Project Will Suffer from Power Laws
Agile is NOT a Risk Management Strategy
Agile Is a Risk Management Strategy

Your Project Will Suffer From Power Laws

You have this great new project. With groovy new technologies, a fine bunch of developers, and a preliminary set of requirements that looks challenging. And now the customer asks you to give an estimate for the release date.

When will you deliver the product?

Uhm...

So you do a bit of estimating, perhaps using the Wideband Delphi technique, and taking into account the Cone of Uncertainty, and then you come up with a target release date of, say, six months from now. And you explicitly tell the customer that the date you're giving is a planned release date, not a promised date. The actual release date can be somewhat sooner or somewhat later. Right? There's probably a margin of plus or minus one month, or something like that. Right??

WRONG!!!

You just made a terrible error.

You forgot about power laws.

Power laws are everywhere. We find them in gravity, stock markets, populations, wealth, fractals, language, geophysics, revenues, intelligence... To name just a few. Power laws are easier to draw than to explain. Here's one:

Power laws are sometimes known as the 80-20 rule, sometimes as the long tail, sometimes a Zipf's Law, sometimes as scale-free networks, etc. But all of those variants come down to the same thing:

The relationship between frequency and magnitude of a phenomenon is not linear, and does not follow a normal distribution. Instead the relationship is polynomial. It's the logarithms of frequency and magnitude that have a linear relationship.

Suppose you were asked to estimate the size of the next earthquake in San Francisco. What would you do? Would you check the size of the last ten earthquakes (= your experience), and then calculate the average out of that? I'm afraid that would be a mistake. The power law is in earthquakes too, under the guise of the Gutenberg-Richter Law.

The distribution of changes in a complex system usually follows a power law. Most often the changes are small, and in rare occasions the changes are huge. You cannot come up with an average or typical size of an earthquake, because there isn't any: "What this [polynomial] relationship means is that there is no typical size in the conventional sense." (Wikipedia)

It's the same with that great new project of yours. Your estimate of the work itself may be fine. But then the real world steps in. And you experience disturbances. Your team leader finds herself a less troublesome job, one developer gets himself a bad social disease, another developer gets himself a wife (which for some people amounts to the same), the new technologies require nuclear workstations to achieve minimal performance, some project manager sneakily snatches away your last developer, and the requirements are multiplying like camels in Australia. Needless to say, your velocity drops like Madoff's credit balance over a black hole. All this, of course, results in a few changes to your planning.

Changes in a complex system follow a power law.

Your six-months-plus-or-minus-one estimate is a mathematical illusion. Forget about it. Reality doesn't follow your smoothly curved normal distribution. Reality follows vicious power laws. There is no typical size for the disturbances on your project, so you cannot calculate an average out of them.

Your project will suffer from power laws.

Pity huh?

(images by Hey Paul, Hay Kranen, and National Resources Canada)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Self-Organization = Anarchy (Part 3)
Self-Organization = Anarchy (Part 2)
Self-Organization = Anarchy (Part 1)

Agile Is NOT a Risk Management Strategy

Last week I told you that agile is a risk management strategy. But it's not.

I lied. (Sort of)

It is true that agile covers all the principles of risk management. I already discussed that last time. And I'm not taking that back. However, agile does not cover the whole domain of risk management. I have three arguments to support my case. Allow me to explain:

1) Agile Does Not Look Inside-Out
In a comment on my previous blog post, Pradeep Bhanot wrote:

"The ISO definition of risk [...] deals with broad organizational and legislative issues at a macro level. [...] Risk management strategy is a continuous process with a long time horizon. Agile approaches are pretty introverted (other than including the customer), and are missing the inclusion of many external factors that a risk assessment would."

Agile software development only looks at the project itself, and the impact that the product has on the customer and the users. But no system exists without an environment. And agile doesn't always take the environment into account.

For example: Only two years ago Microsoft introduced two competing data access technologies: LINQ to SQL and Entity Framework. These technologies were created by two different teams that both were unaware of what the other team was working on. It must have been an unpleasant surprise for both teams to discover a competing product within the organization. And it wasn't just bad for the teams, but for Microsoft as well. Support and migration of customers from one (new) technology to the other is a lot of extra work that could have been prevented. A little risk management might have helped here. (Though Microsoft did decide to release both technologies, apparently for other reasons.)

The teams behind software projects might be very agile. But agile doesn't cover risks to the environment.

2) Agile Does Not Look Outside-In
Have you ever experienced staring at your code for an hour, not being able to find a bug, and then someone else comes along and finds it in 30 seconds? Or (for the non-coders among us) have you ever experienced re-reading a piece of text five times, and then someone else points out three embarrassing errors after just half a glance? Annoying isn't it?

Well, that's the blind-spot problem, and everyone who's ever created something will recognize it.

My argument is that the blind-spot problem applies to any living system, on any level. It not only applies to individuals, but also to entire teams. I've experienced a situation where a team was unable to see a glaring problem that was smiling in their faces while waving a red flag and wearing a tutu. (No, it wasn't the customer.) The team couldn't see the problem because of their blind spot. But I was not on the team. I was an outsider. And I saw it, in mere seconds.

In this case it doesn't matter whether or not development teams are agile. Depending on their level of experience there will be a number of problems that they just cannot see, because of their blind spots. And, being naturally restricted to what happens in the team, agile doesn't cover any blind spots.

3) Agile changes the risk landscape
At the Open Agile conference in Romania I had several inspiring discussions with Corey Haines about the risk of doing agile software development. Corey is convinced that doing only Scrum, without any technical practices, is actually worse than applying traditional approaches. Because, with traditional approaches, there is at least a chance that the code has some level of quality, while with a Scrum-only approach the quality of the code would deteriorate faster than the solvency of the United States Treasury.

I have pointed out a similar issue in one of my earlier articles, where I claimed that agile software development introduces new risks by relying on people being smart, eager, disciplined, etc... When the team lacks any or more of such qualities (and yes, there are more) then you've already got a big problem before you've even started.

Agile is a great tool for managing many risks, but the transition to agile itself is risky business too. Agile both removes and introduces risks. Therefore agile doesn't manage all risks, agile just changes the risk landscape.

Someone should be overlooking the entire landscape...

Three Times a Charm
So you see, there are three reasons why I think agile is not a risk management strategy. Well OK, let me rephrase that:

Agile does some risk management, but it's not a complete risk management strategy.

Yes, the principles of risk management are nicely covered, and many risks are managed, but only for a limited domain of problems. Agile cannot check the whole environment, it cannot see the blind spots, and it cannot prevent introducing its own set of new risks.

That's why people from outside the team need to be involved to cover the entire domain of risk management.

I'm glad there's something left for me to do.
And I'm sure many agile coaches would agree.

(image by neona)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Agile Is a Risk Management Strategy
Risk Management = Banana Peels AND Dollar Bills
Playing Risk: the effect of one little rule

Agile Is a Risk Management Strategy

Some people claim that agile software development is a risk management strategy.

Why?

Because all principles of risk management are nicely covered when you've implemented an agile process.

The International Organization of Standardization has identified the following principles of risk management in their draft of ISO 31000 “Risk management — Guidelines on principles and implementation of risk management”:

• "Risk management should create value."
  In agile projects (re-)assessment of business value, for prioritized user stories, is done in every sprint/iteration.
• "Risk management should be an integral part of organizational processes."
  When you're doing agile, you're doing risk management, therefore it is part of the standard process.
• "Risk management should be part of decision making."
  Every time you prioritize user stories, and every time you list impediments, you prioritize associated risks as well.
• "Risk management should explicitly address uncertainty."
  Uncertainty has been one of the main drivers behind the whole agile software development movement.
• "Risk management should be systematic and structured."
  A product backlog is systematic and structured. And the same applies to sticky notes with impediments on a task board.
• "Risk management should be based on the best available information."
  Meetings involve the whole team, including the Scrum Master and Product Owner, to maximize available information.
• "Risk management should be tailored."
  Retrospectives are meant to tailor the process on-the-fly, to match the environment and the project.
• "Risk management should take into account human factors."
  That's why risk management is done with all stakeholders, and not single-handedly by a project manager.
• "Risk management should be transparent and inclusive."
  The backlog includes all risks identified but not yet tackled. And the impediments on the task board are visible for all.
• "Risk management should be dynamic, iterative and responsive to change."
  Iterative? Responding to change? Now where did I hear that before? It had to do with a Manifesto, or something...
• Risk management should be capable of continual improvement and enhancement.
  Continuous improvement is what retrospectives are for, and it's at the root of everything that is agile.

You can see that all principles of risk management, as required by ISO, are covered by standard agile project management processes. Of course, it requires that risks are identified by both the customer and the team, and made visible on the backlog and the task board. This also fits well with my previous blog entry (Risk Management = Banana Peels AND Dollar Bills), where I wrote that risk management not only covers problems (impediments), but opportunities (user stories) as well.

Some examples of risk management could be:

1. If we don't finish user story A before deadline T the CEO is going to kill someone, and we will have to buy the CIO some flowers when he's in hospital.
2. We better assign user story B to this sprint, because Karl is the best developer to pick it up, and he will go on a 6-month vacation to Louisiana State Penitentiary next week.
3. User story C will deliver lots of business value, but that value will only be earned when we release it immediately after the marketing department finds out about the dead parrot.
4. The team must work hard to keep velocity at a high level, but there's a possibility some resources will be pulled away next week to fix the coffee machine in the executives wing.
5. The customer has not been able to review our latest demos, despite our efforts to beam the demo on the walls of the office building across the road.

 

Every risk identified by the team and the customer is either a user story or an impediment. Risks are evaluated in every sprint meeting and every stand-up meeting, and the team, the Scrum Master and the Product Owner take appropriate measures to manage them.

That's why agile software development is a risk management strategy.

However, I have also good reasons to claim that agile software development is NOT a full risk management strategy. But that's a story for next week...

(images by hellosputnik and the fayj)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
People Don't Listen
Three Levels of Control
How to Handle Many Simultaneous Projects

Risk Management = Banana Peels AND Dollar Bills

I've been trying to think about risk. What is it? What does it mean when we're taking a risk? Five years ago I took a risk when I left the big company I was working for and joined a very small company (at that time). Was that good or bad? And what does it mean when we're doing risk management? I should be doing risk management for the new project I'm working on. Should I be looking for banana peels around the corner? What else?

Here's the definition I found on Merriam-Webster:

Main Entry: risk
Pronunciation: \ˈrisk\
Function: noun
Etymology: French risque, from Italian risco
Date: circa 1661

1: possibility of loss or injury (peril)
2: someone or something that creates or suggests a hazard
3 a: the chance of loss or the perils to the subject matter of an insurance contract ; also : the degree of probability of such loss b: a person or thing that is a specified hazard to an insurer <a poor risk for insurance> c: an insurance hazard from a specified cause or source <war risk>
4: the chance that an investment (as a stock or commodity) will lose value

The dictionary obviously qualifies risk as something negative. It is a potential peril, injury, hazard, or loss, and we would do well to try and prevent such risks from becoming real dangers. We find the banana peel ahead around the corner, and we fling it aside. (Preferably in the direction of that other project that we hate so much.)

Unfortunately, the world is isn't as straightforward as it seems. Here's an interesting piece of text from the article Beyond Detroit (in Wired Magazine), about the American car industry (emphasis is mine):

As [Clayton] Christensen argues in his 1997 book, The Innovator's Dilemma, successful companies in mature industries rarely embrace disruptive innovation because, by definition, it threatens their business models. Loath to revamp factories at high cost to make products that will compete with their own goods, companies drag their feet; perversely, financial markets often reward them for their shortsightedness.

American car manufacturers did see a risk. They saw risk in innovation. But they didn't see the bigger risk that would be the result of not innovating. (In fact, they saw benefits in not innovating.) The saw the banana peel ahead of them, but they didn't see the fast moving Japanese truck behind them. There is always risk in stepping forward. But there is also risk in not stepping forward. Humans often only evaluate one side of change: what problems might attack us when we do this? And then they forget about the other side: what problems will attack us when we don't do this?

But there's something else that is often overlooked as well. Here's what Wikipedia says about risk (emphasis is mine):

Risk is a concept that denotes the precise probability of specific eventualities. Technically, the notion of risk is independent from the notion of value and, as such, eventualities may have both beneficial and adverse consequences. However, in general usage the convention is to focus only on potential negative impact to some characteristic of value that may arise from a future event.

Risk can be defined as “the threat or probability that an action or event, will adversely or beneficially affect an organization's ability to achieve its objectives”

So... Risk isn't just about negative things happening. It can just as well be about positive things. What's around the corner may not be banana peels but dollar bills. Have you noticed how global warming is exclusively portrayed in the media as a change with potentially negative results? The risks we've been warned against include flooding, hunger, malaria, and many more perils. But where are the positive effects of global warming? And who gets to say what's good and what's bad?

Here's another interesting little piece, this time from the article Gaia's Evil Twin (in New Scientist):

Perhaps the worst event of all was [...] the evolution of photosynthesis and the rise of atmospheric oxygen. Until that time, living things could not tolerate oxygen - it was a deadly poison to the microbes that constituted life 2.5 billion years ago. With the evolution of photosynthesis a weapon of mass destruction was unleashed, creating the first, and perhaps the most extreme, of all mass extinctions. Life was devastated. All that survived were photosynthesizers and microbes that evolved rapidly to tolerate oxygen.

Oxygen? A deadly poison? It depends on your viewpoint, doesn't it?

2.5 billion years ago, photosynthesis was a deadly risk for many microbes. It was a banana peel of epic proportions. But not for the few that were able to adapt. They found the jackpot. They saw most of their competitors being wiped from the face of the planet. Goodbye and good riddance! And no hard feelings, we hope. A deadly risk for one is a great opportunity for the other.

 

I can summarize my points with this simple little table:

action / risk	negative	positive
no change	A :-(	B :-)
change	C :-(	D :-)

When people talk about change and risk management, they usually focus on quadrants B (the positive things to say about not changing) and C (the negative consequences of change). And they easily forget about the two other quadrants of risk management: A (not changing can be worse than changing) and D (who says that change is a bad thing?).

Proper risk management covers all quadrants of the table. Risk management is about negative and positive effects. Not changing is simply a choice to go in the opposite direction, with similar but reversed consequences (positive and negative effects).

Now, I'd be really happy if someone could give me a reliable way to predict whether banana peels or dollar bills are behind me, or ahead of me around the corner...

(images by Knut Burmeister and Doublep1)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Accountable or Responsible?
How to Do Things Your Customer Didn't Ask For
Your Project Has No Goal