Confront the brutal facts

Confront the brutal facts was a challenge from Chet Richards’ keynote at LSSC11 and I believe he borrowed it from the book “Good to Great” by Jim Collins.  In my opinion, there are at least three key things this challenge brings to light.  Firstly, something(s) is negatively impacting the performance of an organization.  Secondly, we need to find the facts that are brutal, not just the everyday-run-of-the-mill facts.  Lastly, it’s not just good enough to know the brutal facts, they must be dealt with.

Merriam Websters defines brutal as: very bad or unpleasant.  A brutal fact is something that is both very real and not terribly nice.  Being unpleasant is obviously context bound and relative to an organizations particular situation.  My brutal facts are not my next door neighbors brutal facts.  Examples of brutal facts in software development could be consistently delivering software into production much later than originally planned, having builds fail every time code is checked in or not having a technically competent team.

Truth be told, many organizations defer, downplay or outright avoid identifying brutal facts because the exercise of doing so is both self-revealing and self-indicting.  Who really wants to talk about what’s going wrong?  The teams I’ve worked on have never had a problem talking about the good stuff we were doing, but talking about our mishaps never shared the same enthusiasm.  This unpleasantness is due largely in part to the fact that identifying brutal facts is often conducted as a highly subjective exercise with no concrete data to go off of.  When meaningful data is not collected, its challenging to even determine what the brutal facts are let alone possibly address them. Because of our “ladders of inference”, we need data that we can all try to agree on.  If you truly want to identify brutal facts you need to collect information and track/measure important indicators.  You need to be an organization that is desperate to learn.  Unfortunately, too many organizations measure stuff that doesn’t really matter, but that’s a topic for another day.   Revisiting the example of functionality being delivered late, if a team had collected issues/blocks/impediments during the development cycle, identifying the brutal facts possibly becomes a simple activity of reviewing the impediments.  The review could reveal that the development team doesn’t have the access it needs to the end users or subject matter experts for clarifications on how the system should behave.  Combining information like this with techniques such as the 5 Why’s can make identifying brutal facts a bit easier.

That being said, you don’t get brownie points for identifying brutal facts, no my friend, no gold stars for you.  Brutal facts need to be addressed.  The word confront carries with it what could be considered a “negative connotation” but I appreciate the choice of word here because it conveys an attitude of an active and aggressive attack on brutal facts.  That being said, it’s so very easy to address brutal facts incorrectly within an organization.  An improperly addressed brutal fact can actually do more harm than good in same way that trying to kill a fly with a hammer is an idea that can leave you with a busted thumb and broken glass all over the house.  In fact, you may be better off leaving the brutal fact as is if the only alternative you have is to address it incorrectly.

Why do we fail do address brutal facts effectively when they are identified?  I would suggest that this is due (at least in part) to our traditional analytical problem solving approaches i.e. looking at the brutal fact in isolation and not seeing it as part of a potentially larger problem.  A classic example of this is the persistent notion that the way to solve the software delivery problem suggested earlier is by adding more developers.  However, adding more developers would obviously just worsen things.   Unfortunately many organizations struggle to look at things in a holistic manner because they do not have the necessary eduction, training and skill required to address issues holistically within the organization.  This where I believe an understanding of Systems Thinking can significantly help teams and organizations address brutal facts in a holistic manner.  A book recommendation for that would be Peter Senge’s: The Fifth Discipline: The Art & Practice of the Learning Organization.   Systems thinkings in of itself is not a panacea – nothing in isolation is – but looking at the whole system hopefully gets us moving in the right direction.  For the team that does not have the access they need to SMEs, the organization could make a decision that SMEs need to set out an hour each day to address questions from the development team.  That could be a holistic solution.

What brutal facts plague your organization? Are you up to the challenge to confront them? I hope you are!


Enough Already!

I’ve found that trying to blog about my experience at LSSC11 is quite challenging simply because I have a flood of thoughts streaming through my head.  Frankly, I’m not sure where to start and where exactly to end.  I’m concerned that if I try to share all my thoughts in one post, it post will never end.  Because of this, I’ll publish my thoughts in a series of short postings over the course of the next couple of days (or weeks) as time permits.

For starters, LSSC11 was the first conference I’ve been to (maybe ever?) where there were no sacred cows touted, no best practices elicited and no meaningless debates between method X versus method Y.  I believe we’re coming to a place where we’re starting to accept as a community – yet a minority in my opinion – that there is no “silver bullet” but that the right combination of principles from differing sources can possibly yield great results.  We’re accepting that our environments are complex and are leveraging methods that exploit this fact instead of fight it.   We are discussing how to make people “matter more” because we realize (even more) that its people that really make a difference.  Finally, continuous learning is paramount; LSSC11 had an academic undercurrent to it which I’ve not observed at any other conference.  The list of reference material I need to read has doubled in size!

To summarize, I sense a movement that is saying very loudly and clearly “enough already” to some of the traditional ways of getting things done and is looking to embrace different ways (some that have been possibly rejected or ignored for years) as we move forward.  This is really exciting, make sure you don’t miss out!