Agile antipattern: Hiding unfortunate truths

“Unfortunate truths” are things which are true – unfortunately!  I’ve heard the phrase used by defense lawyers and I have to admit it is pretty funny to hear something like “Well, my client would have been found not guilty except for the unfortunate truth that his fingerprints were on the weapon.”  Seems to me it was a FORTUNATE truth from the viewpoint of the rest of society!  We can look at the example I just gave and think it is pretty silly.  Then we turn around and do the same thing on our agile projects.  We might think hiding our head in the sand will help us avoid seeing the problem, but instead it just tends to make us look too much like the major piece of anatomy which is left sticking up!

For an agile team an unfortunate truth generally falls into one of two categories: a) something which shows we will not meet our iteration commitment, or b) something which shows we will not meet our project success criteria.  Members of new agile team tend to try to hide more unfortunate truths than longer running, successful teams.  I consider this one of the elephants in the room which needs to be exposed and removed.  But even on some successful agile teams there are individuals who tend to hide unfortunate truths.  Let me be very clear on something:

Agile is designed to expose risks early!

If you are not doing so then the process has broken down.  Remember, exposing risks early means there is more time to deal with the risk and make it be a non-factor.  By hiding unfortunate truths you are robbing the team of valuable time it might need in order to change the amount of “unfortunateness” (ok, maybe it isn’t a word, but it sure was fun to type!).

In closing this post I want to point out we all have different definitions of what constitutes an “unfortunate truth.”  For example, I might consider it an unfortunate truth my glass is half-empty.  Someone else could easily consider the same scenario fortunate because the glass is half-full.  My point here is simple – don’t impose your definition on the entire team by not raising the issue (umm, everybody, we thought we had a full glass, but we only have a 1/2 glass).  Every member on an agile team has a primary responsibility for exposing potential risks.  In fact, it is ok when looking at risk to be incredibly pessimistic so the worst case scenario can be turned into success!  Many times the risks are not real, but imagined.  This is fine, the system worked as designed if someone says your perceived risk isn’t really a problem.  However, when the risk IS real, having maximum exposure of the problem (ie, not hiding “unfortunate” aspects of it) combined with having maximum time to mitigate the risk often mean the difference between success and failure.  Help your team be successful by shining light on the unfortunate truths others don’t want to face.

Until next time I’ll be Making Agile a Reality™ by erasing one unfortunate truth at a time.