Change is coming

Conventional wisdom suggests that change is to be feared and, moreover, change agents should exercise extreme caution when effecting change. But let’s look at what goes on today in our own worlds and admit that we barely notice the changes that affect us and only occasionally speak up about them.

In this article I want to address to sacred cows of change. First the lore that says we have to cosset those upon whom change is about descend and make their transition to change as painless as possible. And second I want to address the notion that change has to be optimized and efficient and error free and perfect.

Unannounced change

Daily, it seems, our mobile devices are being updated by the app vendors we have invited on to our phones and tablets and by the operating systems vendors of those platforms. For the most part we welcome the changes, many are “under the covers” performance and security but many are user interface and usability. If we don’t like the changes we shrug and soon get used to them.

Facebook notoriously changes its privacy policies and user interface without so much as press release or an on-screen warning. Google takes functionality away without apology. Mismatched capabilities between mobile and browser applications continue to frustrate and annoy. Yet, amid all the short-lived and half-hearted vilification from the press, millions of users adjust, adapt and accept.

So is this a model we can apply to enterprise software change. Should we allow software vendors to overhaul their solutions and still expect our loyalty? Should we be able to revamp our own custom applications without all the extensive user training and preparation that we often factor in to the roll out plan?

Imperfect change

Analysis paralysis is the worst stage in the change process. When we sit down to review what it is that we are going to change we often find ourselves debating the merits of some nuance of change far in excess of the importance of the point being discussed. Indeed there are times where the time spent in deliberation of these points exceeds the total amount that could be possibly saved by implementing a solution around it.

Conventional wisdom also says that we should improve the processes we are changing. What is wrong with simply automating the existing process as-is? The very fact that the process is now automated improves it (usually). Even if that automation automates inefficient, error laden, duplicative and disorganized process: it is still better than the manual (or old automated) system. Because it can be tweaked, streamlined, simplified, enhanced and improved without sending memos, without wholesale training and without months of debate.

From a learning perspective we find it easier to learn a new way to do something we already know how to do than to learn a new activity altogether.

Standing on our heads

Our systems, processes, methodologies, best practices, policies and procedures were all conjured up in a time of delivery life-cycles measured with a calendar. We lived in a world that was predictable and when shifts occurred we had time to consider the implications and adjust accordingly.

We don’t live there anymore.

Now we expect delivery in seconds. The world can change in an instant. New competitors can be undergraduates in their dorm rooms. New products can replace us with the cloud. New cost models ignore bricks, mortar, infrastructure and salaries. Marketing is done by friends of friends. And change is what the author says it is going to be.

The pressures for change are immense forces weighing on us at every moment. The pressure to meet the dynamics of the market as it shifts faster than even the pundits can track. Pressure to drive out cost. Pressure to innovate, delight and surprise. Pressure to be first to market today and again tomorrow. Pressure to not get your executives sent to prison.

Numerous responses are in place to address these factors but they still operate in a world that is geared towards the old, considered cadence of change.

So it is time to ignore all the old strictures and do what our instincts tells us we should be doing. And that is change: change everything so we can change anything.

Not so crazy after all

In all enterprise organizations and in not so large ones too, there is a change process. It is well documented, probably well automated and it is very well policed though often understaffed. And there is always a second process, an emergency process, designed (originally) to get critical fixes into the production environment without going through all the stages gates that “normal” changes go through.

You might call it your “unplanned change process”, or your “emergency fix process” or your “exception process”. Whatever you call it, it is a short cut to getting changes made. These changes are small and therefore have little impact or risk associated with them. They are easy to test, easy to deploy and easy to back out if something does go wrong.

Every organization tracks these changes and for many these changes amount to a small percentage of the total changes that go through their change control process. But for many more organizations they have seen the trend of these changes increase and increase dramatically over the past decade. What were once the rare exception is now commonplace. And that is odd because in that same decade software quality has improved by several orders of magnitude and project planning and delivery has become pretty reliable (and not so much of a horror story reported in the Standish Chaos Report).

But still the trend for the “emergency” change is on the rise with business focused individuals using the unplanned-change route for business process changes and to meet time-to-market needs. Indeed some organizations report that these kinds of change are becoming the norm.

Near enough is often enough

We should also remember that the 80-20 rule still applies. When we implement a change it is usually perfectly fine to spend 20% of the effort to implement 80% of the requirement. We have, for too long, been in the habit of addressing every corner case, every rare and random exception. The truth is that most businesses operate in a world where exceptions are being eliminated in order to make the business more efficient. So the 80-20 rule may well be a 99-1 rule in reality as far as the data is concerned. So let’s cover those cases first and see what happens.

We have to learn to ask the business to make choices. Would they prefer elegant and slick interfaces? For customer facing applications: absolutely! But for internal ones: heck no. Would they prefer every use case covered by automation? If it can be done in a week, but not if it takes a year.

Let’s take a leaf from the App Store and invite users to comment on the changes we make and help us prioritize what gets done next.

Are we already ready for this

Our change infrastructure is already designed to manage small, incremental changes on a daily basis. It is what the business wants. Maybe the paradigm is shifting and those major project works are the new exception.

We are no longer frightened of change, we see it daily on our smart phone and tablet and so do the end-user community. We have become very sophisticated at the business of change and have excellent tools and processes in place to manage change. Daily we remove more and more aspects of the manual management of change and hand it off to automated code migration, automated builds, automated testing and automated deployment.

If we ask the business “Do you want those 10 critical changes and the 90 nice-to-haves in 6 months OR those just the 10 critical changes in two months’ time?” we know what the answer will be. They will say “Give me the critical stuff when it is ready and the rest when you can”.

Can we just switch over to this new way of working overnight? Perhaps but a few cautionary suggestions first.

We need the business to talk to us in terms of priorities. They have to tell us what matters the most to them and not deluge the organization with every change they have ever considered. This means the role of the “product owner” needs to be strengthened to keep the business focused.

Delivery dates and keeping to schedule becomes less of an issue. Stuff is done when it is done and some of that stuff needs to match up with external needs like marketing campaigns or legislative dates. So let’s back off the tracking to dates on those projects that are not time sensitive. After all nothing needs to make some release train date any longer.

We have to automate as much of the change and release process as possible. The volume of changes will not change (100 changes that are each their own projects is the same amount of change as one project of a 100 change requests) but the individual administration of each change will. So we have to rethink the approvals cycles and the test cycles.

Test automation is once again critical. Changes that do not affect the user interface ought to be able to go through entire battery of tests before deployment. Indeed the automated test tools should be moved into the hands of the developers: why hand off bad code to the test team, code shouldn’t leave the developers until it is passes every test that is practical to do.

Communicating changes to the business needs to happen but it can be done through social media, YouTube videos, a developer blog, wiki’s and the like. Change the model from we must “push” information out to the users to the users should be able to “pull” the information they need.

We have all the technology we need in place. The business expects it of us. We are doing by another name already. Isn’t it time we made it a legitimate practice?