Change is the currency of every organization involved developing, enhancing or maintaining software. Change includes the business process being automated, the techniques used to do work or even the technology upon which the software is built. Very little significant change is frictionless. For change to occur the need and benefit to be gained for solving the problem must overcome inertia, the work needed to find a solution and implement the solution.

I recently purchased a new pair of shoes, an act that I had put off for a bit longer than I should have. The pair of shoes I had owed for three years but had been wearing nearly everyday for the last year were a pair of Italian loafers. The leather was exquisite over the three years I had owned the shoes they had become very old but very comfortable friends.  Unfortunately the soles had worn out and because of how the shoes were constructed, they we’re not repairable. As a rule, consultants wearing worn out shoes, however treasured, generally do not confer confidence. The hole in the sole and a need to earn a living established the need for me to change.  The final impetus to overcome inertia was delivered when I found that an important meeting on my schedule in the next week. Why was there any inertia? Unlike my wife, I can’t order 10 pairs of shoes online and then return seven after trying them on for a few reasons. First my need was immediate, the worn out soles were obvious to anyone sitting near me. Secondly, I am fairly hard to fit when it comes to dress shoes. Shopping (something I find as enjoyable as a prostate exam) is an event to be avoided. Deciding to change/shop requires an investment in effort and time. Almost every significant organizational changes require the same upfront investment in time, effort and rationalization to break the day-to-day inertia needed to begin to pursue change.

Breaking through the barrier of inertia by establishing a need and weighing the benefit to be gained by fulfilling that need is only the first step along the path of change. All leaders know that change requires spending blood, sweat and tears to find the correct solution. A team that has decided to change how they are working might have to sort through and evaluate Agile, lean or even classic software development techniques before finding the solution that fits their needs and culture. The process is not terribly different from my shopping for shoes. The shoe story continues with a trip to the local mall with two “major” department stores. Once at the mall I began the process of evaluating options. The process included an hour that I will ever get back in one store being told that that there were no size 10.5 shoes in black that would be suitable for an office in stock. Then being offered a pair of 11’s that I could lace up myself to try on. The last caused me to immediately go to another store where I bought a pair (my normal brand in stylish black). Just like the team finding and deciding on a new development framework, I had to evaluate alternatives, try them on (sort of prototype) and then negotiate the sale. Change is not frictionless.

Once an organization decides to change and settles on how to they will meet their need, implementation remains. Regardless of all the ground work done up to this point important but not sufficient effort and … sometimes pain are required to implement the change. Teams embracing Agile, kanban or even waterfall will need to learn new concepts, practice those techniques and understand that mistakes will be made. Looping back to the shoe story, I am now suffering through a blister. Organizational process change might might not generate physical pain like new shoes however to stress of the change has to accounted for when determining if the cost of change is less than the gains foreseen for addressing the need.
In the end, change is unavoidable whether we are discussing new shoes or process improvements. The question is rarely, will we change but rather when we will change and how big a need do we have to generate to offset the effort and aggregation that any change requires.

Now for something completely different!

I need your help! I am proposing a talk at AgileDC (Washington DC, October 26th). The title is

Budgeting, Estimation, Planning, #NoEstimates and the Agile Planning Onion – They ALL make sense!

Can you go the AgileDC site and like the presentation (click the heart next to the title). The likes will help get the attention of the organizers! I would also like your feedback on the topic.