The Black Swan concept is based on an ancient saying which presumed black swans did not exist. People mistakenly thought that the fact that no-one had even seen a black swan, meant that they didn’t exist. (The saying was rewritten after black swans were discovered in the wild!) Nassim Nicholas Taleb popularized the term in his 2007 book The Black Swan: The Impact of the Highly Improbable. Taleb talks in his book about events or occurrences which that deviate beyond what is normally expected of a situation and that would be extremely difficult to predict.

What could possible go wrong?

The range of unexpected occurrences that can derail a sprint, or a project, is wide and varied.  From my own experience I’ve picked a few of the more exotic unexpected events that have impacted projects that I’ve worked on.

• One of the software developer’s goes on holiday and his temporary replacement reports that much of the developer’s code, which he claimed to have written himself, actually came from another company (as determined by comments and digital signatures).
• Volcanic ash grounds all international flights meaning that primary stakeholder is unavailable for meetings for several days
• Developer has a stroke and is unavailable for an undetermined period of time
• Lose access to all corporate computer systems for 3 days for never-completely-explained reasons.
• Product owner violates employment contract by accepting job with competitor and is escorted off premises immediately after this is discovered.
• Key stakeholder has nervous breakdown and ends up in psychiatric ward
• Users at one office band together and refuse to pilot the new solution.
• Vendor’s Project Manager catches Tuberculous.

This is just a sample of the types of unexpected things that regularly occur to derail even the best laid plans.  In traditional Waterfall models of development, such occurrences can have major negative consequences on a project.  And let’s be fair, these type of unexpected events will also have an impact on Agile projects as well.  But I’ll argue that Agile methodologies handle these unexpected events much better than traditional methods, enabling progress to continue in a much better fashion than traditional methodologies allow for.

Why does Agile handle Black Swans so well?

Agile almost expects the unexpected. There are a number of key parts to Agile that deal with unexpected Black Swan-type events most effectively.  I’ll  expand on some of the most powerful aspects below.

The Art of the Possible

A key part of the Agile mindset, and one that is often overlooked in my opinion, is that Agile is “the art of the possible”. In whatever situation, no matter what the circumstances or unexpected events, we focus on what we can do to move closer to delivering business value (rather than focusing on the obstacles).

Small Experiments

A key part of the Agile mindset is that the future is unknowable, and the best way to deal with this is to do small experiments and then empirically assess the results.

By doing small experiments /small bets/sprints we are effectively reducing our risk profile.  Should a significant unexpected event occur, then in many ways the worst it can do is derail our (two week) sprint/iteration.  And then we re-assess what we can do during the next sprint/iteration planning meeting – which is pretty much what we would be doing in any case.

Limited WIP

Small experiments and sprints are ways of limiting our Work In Progress (WIP).  Systems that don’t limit WIP can invest significant resources in having large amounts WIP, and the face high costs if all WIP has to be halted for some reason. One advantage of limiting WIP is that if something should contaminate the process, or causes the process to stop, then only the WIP is affected. All the remaining items in our backlog may be affected to some degree by the unexpected event, but since we haven’t invested any resources in them, we don’t incur the same large penalty costs.

Focus on Value

In Agile we prioritize based on business value (rather than speed, cost, ease etc). By focusing on completing the highest value items first, we ensure that should a Black Swan event happen then at least we have completed the most important work.

Potentially Shippable Product

Agile methods aim to produce a potentially shippable product at the end of every iteration. By delivering a potentially shippable product at the end of every iteration, we ensure that even in the case of a Black Swan event, we have something workable that we can potentially go live with and gain value from.

Embracing the Black Swan

Black Swan events have occurred throughout history and my guess is that they will continue to occur going into the future. I’ve given you a number of Black Swan examples from my own experience and I’m sure that you have some from your own experience as well. Due to their unexpected nature, it’s quite frivolous to try and predict when they will occur.  But we should have a plan for dealing with the unexpected. The approach I like to adopt is two-fold. First, monitor your activities diligently. Second, deal with what whatever happens.