Over the last twenty years many organisations have undertaken an Agile transformation.  Often the reason for going down this difficult, often expensive and lengthy road is of course to enable an organisation to deliver more customer value, more quickly through using responsive techniques of planning and development.

However it is not unusual for a whole transformation to eventually pivot around a central tenet like “We do Scrum here” or “We use JIRA” or “We’re using VSO/VSTS/Azure DevOps”.  A transformation may start with the lofty ambition of smoothly and simultaneously convert the organisation into an Agile one, but the pressure to ‘keep the lights on’ can always provide a distraction for busy organisations. We often see transformations reduced to an attainable lowest common denominator in an effort to produce some measurable value.

When it comes to delivering software and IT, with the advent of the johnny-come-lately in the form of DevOps, large numbers of technical tools have also come to define this era of transformation. It is at a point where it’s not unusual to see IT recruiters studying tables of DevOps tools and languages in order to understand this complicated landscape. It’s a sign that it has become increasingly difficult to communicate just what the Agile and DevOps transformation is about without confusing the tools, the techniques, the frameworks and the attitudes that we would want out trainers and leaders to instil.

This is a hard message to get right.

While some individuals are built for disruption and are happy to accept, embrace, and even drive-through change in their own organisation, a lot more require convincing about the benefits of transformation. When we talk about a Scrum team being made up of only Developers, and that Testers and Business Analysts no longer exist as a concept (according to Scrum principles), then how do people recognise themselves in this new role? Does it challenge their concept of self worth?  Their job might entail fulfilling pretty much what they did before but they are also expected to learn new tools and techniques and be more ‘Agile’ in their approach to their role.  We hear that everyone needs to become more ’T shaped’ but surely we shouldn’t be judging everyone we’ve already hired to somehow now ‘pivot’ into a new form of themselves?

What we are asking people to do is to fundamentally change their their way of working often without giving them a clear idea of what this actually means day-to-day in terms of details. Sure people can start using JIRA but how does this benefit them?  It’s very easy to see why all of this can be confusing for the people who have to do the hard work of their job as well as learning a new way of working during this type of transformation.

We often talk about Agile and DevOps transformation being a cultural one – however does that mean that those that don’t fit our culture should expect to have to leave the organisation? And how do we make this change happen – from the grass roots where there is often inertia that prevents us from getting effective change, or from top-down to announce or show how change from the top of the organisation can improve it?

The challenge of transformation not only redefines peoples’ relationships with each other but also with their firm. It can be stressful and confusing to feel ‘redefined’ in this way even if your actual responsibilities haven’t changed.

Unless we can show that there are clear benefits for everyone involved in a change exercise then surely there is surely no reason to expect everyone to do so.  Or should we just expect everyone to go along with it – to “rubber stamp” the procedure. Is this a healthy and cost-effective way forward for any organisation?

How do we make Agile and DevOps more achievable and beneficial for both individuals and organisations?  And also is putting too much focus on delivering customer value detrimental to the organisation as a whole?

I’ll explore this more in my next post about this subject which will highlight the fundamental tension between the goals of Agile and Devops transformation and discover how it is dependent on your perspective and expectations and, importantly, customers.

About the Author:

Richard is a DevOps and Agile transformation leader with a software development and IT infrastructure background.  He has worked on many transformations in many leading banks and insurers and is always looking to promote sustainable benefits from change at an individual, organisational and customer level.