Grasping Agility: Agility, Personality and Failure

I’ve never been much of a blogger. The concept of short but frequent commentaries on subjects causes the perfectionist in me horror.  I hate failing on a deep visceral level. Even my small failures tend to cause me distress for weeks or months after whatever the mistake was.


My personality tends to stop me from starting things that may fail, but others deal with failure in other ways. Some try to hide the failure, others deny that a failure is actually a failure and continue to go along without making any sort of correction.

In business today my personal preference for failure avoidance is typically not an option. If we don’t do anything we don’t make money and we are probably involved in defrauding investors somewhere along the line, so we will just brush that one aside for the moment. The other two are the ones that I would like to address, because these are what Agile and very specifically Scrum looks to help us overcome.

This difficulty often results in failure, as it should. Sadly the reaction to this failure is all too often; “We can’t do this” when it should be “How can we make this work”. The software industry has clearly demonstrated that Scrum is not only possible, but optimal. There is no business that Scrum could not be applied to successfully (should it be applied is another debate).

In truth, dealing with the problem of an organization trying to hide failure is a simple one, all you have to do is practice Scrum and everything will surface. Dealing with the denial of failure is a bit trickier.

In most software organizations we are conditioned to be horrified by failures because in a traditional waterfall structure they are catastrophically expensive. At best we have lost months of work, and at worst, years. Scrum allows us dramatically reduce the impact of these failures by taking them to a place where we have lost 2 weeks at most, or more typically a day or two. The trick is that even though these failures are not costly, our reaction to them is the same as if they had been. We don’t see them as the valuable knowledge growth they represent;  we see them as the end of the world.

In any sort of bureaucracy the instinct to hide or deny is strong, but if we can bring people around to an understanding that failures are simply part of the normal course of business, to be learned from and used to drive adjustments, we can start to overcome the denial.

In the end it is all a culture shift. Adopting Agility in an organization requires self-reflection, asking ourselves why we react as we do to failures. Admitting that aspects of our business that we just assume to be “normal” are actually failures and should be addressed comes with this. It’s a frightening thing to put together a proper list of impediments to success, but a necessary one.

Scrum shows us what is wrong, but we still have to fix it. The final, and most important piece of this is understanding something that years of conditioning has destroyed in most organizations; Just because something is broken doesn’t mean we have to fix it today, or ever. Part of why we hide, avoid, and deny failure is because we think that as soon as we know about it we have to fix it. Not true, not even possible in most cases. We have years, decades even, of problems to resolve, it’s going to take a while, but if we don’t dredge them up, admit to having them, and work out a plan for fixing them, they never will be.

Caleb Brown

Caleb Brown is an Agile trainer, organizational coach, and Certified Scrum Professional with a focus on the the “People Side” of software. While practices and technology are part of what enable organizations to succeed with Agile, Caleb likes to concentrate on using the cultural piece supported by whatever practice, process, framework, or technology is needed to be successful. Having worked on the technical side of the software industry since 1999, and as CollabNet’s Product Owner and Master ScrumWorks Trainer since 2007, Caleb has gained deep insight into the inherent challenges with Agile adoption. His trainings and expertise in helping global organizations understand where process ends and tooling picks up, is well respected and highly sought after.

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *