What’s In Your Attic?

Posted by Rich Crowley in Agile, Change, Personal Improvement, Project Management, waterfall

One of my favourite books is Steinbeck’s “The Winter of our Discontent”.  In it, he writes “So many old and lovely things are stored in the world’s attic because we don’t want them around us and we don’t dare throw them out.”

I love this sentiment.  It can be applied at a personal level, organizational level, institutional / societal level or at almost any abstraction one cares to apply it to.  These lovelies in the attic could be ways of doing things, tools used to build things, people / roles, places, processes, etc.

It’s an intimidating idea to chew on.

At a personal level, I have come to the realization that my attic isn’t necessarily full of stuff, but some of the stuff in it is getting pretty dusty.  It has been a long time since software development was actually part of my job but I still view it as a wonderful craft and an enjoyable pursuit.  Since I work primarily in an office environment, I find it harder these days to spend my non-working hours coding at a computer as a hobby.  And yet, as I write this, my trusty old MacBook Pro sits beside me, with bits and pieces of code and apps awaiting my next feverish bout of feeling the need to build something in binary.

At an organizational level, the attic can be pretty full and dusty at the same time.  The classic item I see again and again is the legacy system.  Built or bought years and sometimes decades ago, such systems were at one time the newest advance in technology being applied to solve thorny problems in a bid for competitive advantage.  Over time, they were patched up when they broke, glued to other newer systems as the domain evolved until one day they got old and now run in some location and on some platform that only a few (soon to be retiring) people know about. Often supporting only business exceptions (ie. older products / services / practices, etc.), such systems could often have business cases built that support just unplugging them and letting go of the activity that still runs on them.  Usually, it is just too scary or risky to consider making this leap however and so in most cases, the dust piles up.

Roles and processes are also among these attic items.  As someone who makes his living working on projects, I see it in the traditional project manager role and project planning / execution frameworks.  The PM-BOK view of things, while worthy in the right context, is showing its age in an era where speed and agility rule.  I consistently read and hear that digital projects are different and waterfall doesn’t work for them the way agile does / will.  I’m not sure I agree because from my perspective, I really don’t see significant differences between projects in today’s digital landscape over projects from many years ago.  Having said that, waterfall had a mixed record of success at best and agile / lean approaches were born out of some of waterfall’s pain points so I do believe it is an improvement / evolution.

On the flip side is that while agile has many good things about it, there needs to be a commitment within any organization that tries to transition to it, to really understand the fundamentals behind it, to educate those participants who will take part in agile initiatives, to re-cast roles and team dynamics expectations, and then to integrate it into management processes and reporting mechanisms that will likely continue to exist in their current form.  To ignore these concerns risks sabatoging the good things agile / lean approaches can deliver.

A colleague of mine who is an Agile transformation consultant told me recently that he is working on an assignment in a large bank where the decree came down to “go agile”.   He outlined lots of really wonderful things that have been accomplished in a short time but chuckled when he described how difficult it was to do away with the program steering meetings, status reports and program / portfolio dashboards, resource planning and approval processes, etc.   Alas, while some of these are painful to keep in the transition to agile (and it wasn’t clear who should / would be responsible for them), they decided not to throw them out just yet.