OpenCredo’s Agile Transformation

Why Transformation?

Change causes ripples which reach much further than you would think

For years, OpenCredo has been working with organisations to help them introduce new technologies, and more effective development practices, to their IT teams. This has met with a great deal of success, and we have worked with a variety of companies of various sizes. During these projects, we have consistently noticed that the changes we make reach beyond IT in their impact and effects. Making changes in IT is like throwing a stone in a lake. The change causes ripples, which reach much further than you would think when just looking at the problem you’re helping with. We have, over the years, gotten better at helping companies work through these changes, but we have also seen a need for people who can help the rest of the organisation deal with the challenges posed by a rapidly changing IT department. For that reason, we’ve expanded our services to include Agile Transformation – a service designed specifically around working with organisations to adapt to IT departments that are capable of easily and rapidly turning customer requirements into deliverable features and products.

Many organisations struggle with how to work in rapidly progressing IT environment, and depend on infrastructure and software developed when the world was a different place¹. In this world, IT Operations teams function as gatekeepers, wary of pushing anything live that might result in having to work out of hours; developers are pushed to get features out the door before they’re ready, on software that’s difficult to change, update, and manage; quality assurance never has enough time to test things properly; and disasters inevitably occur. All this results in management wanting more controls in place, believing a stricter release process will result in fewer problems in their production environment.

When all these things are combined, IT has trouble delivering real value to their end users (sometimes a client, sometimes a customer, sometimes an internal user). As far as users are concerned, the internal workings of the IT department are irrelevant. They want to be able to tell someone what they need, and then have it delivered in a reasonable timeframe, in good working order. If we start with this drive to deliver value as our end goal, we can see that traditional IT practices have almost done the opposite.

Transition

Before making the transition from existing IT practices to new ones, it’s best to have an understanding of the potential impact – Who will be affected, and in what ways? What changes will it bring? Who wants those changes? Who understands them, and who doesn’t? Who feels threatened by the coming changes, and how can those feelings be brought out, understood, accepted, and addressed?

In a time of such massive change, and potential upheaval, it can be very difficult for management and staff to work together. There is a mistrust built into something as big as an entire infrastructure shift. Management wants to make progress, while staff are afraid of losing their jobs. Management talks about agility and lean, while staff hear redundancies. In this sort of environment, it is important that somebody can come in and listen to what everybody says and feels, and help find a path forward. The key here is listening. Everybody has something valuable to say. Everybody has something to offer. And everybody finds it easier to commit to something when they know that they have been heard².

We get a good idea, from listening, of what’s on most people’s minds. It also helps us put together a picture of the overall technical and non-technical position of the company which, in turn, allows us to identify challenges which, once addressed, will have a disproportionately positive impact on how the organisation functions.

Regardless of the challenges we come across, there a number of benefits of resolving them, including:

• Faster reactions to user requirements
• Increased pace of innovation
• Higher morale among staff, resulting in
  • Decreased turnover
  • Improvement in the quality of work
  • Fewer errors
• Improved communication
• Reduced impact, or existence of, silos
• Increased collaboration
• Fewer issues lost between the cracks
• Improved understanding of what everybody is doing
• Lower costs
• Simpler, better understood architecture

Conclusion

While not every company sees every possible improvement, we’ve found these to be pretty consistent across our projects. Historically our focus has been on delivering the more technical of these requirements, but the impact of the non-technical requirements has been so great that we think it’s time to tackle it as an integral part of our work. We’re really excited about the future we see, and are really looking forward to dedicating time within our projects to explicitly addressing things we have previously done incidentally.

———————

Footnotes:

1. The Phoenix Project
2. Fair Process Managing in the Knowledge Economy

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.