The corporate landscape has become somewhat obsessed with the concept of Digitalisation in the last years. It has led to a plethora of conferences on the topic and lots of executive work on the delivery of a ‘Digital Strategy’, however, I feel many practitioners haven’t taken time to consider what elastic concepts like ‘Digital’ actually mean. This is hardly surprising as the term has been notoriously difficult to define. Even our esteemed colleagues at McKinsey acknowledge this ambiguity noting that ‘digital should be seen less as a thing and more a way of doing things. If we really must have a definition, I am partial to Microsoft’s adage that ‘Digital transformation is about reimagining how you bring together people, data and processes to create value for your customers and maintain a competitive advantage in a digital-first world.
However, I think it is important to note that some of the concepts relating to ‘the way of doing things’ associated with Digital transformation such as Agile Development significantly predate this current fad. In fact, the Agile Manifesto was originally published 18 years ago! Now part of the problem with the word agile is that it can often be understood in its original context in the Oxford Dictionary as ‘being able to move quickly and easily’ or to quote their example, ‘as agile as a monkey”. But once you take the time to work with and deliver software-based on Agile Development methods, you will find that to be successful, you need to stick to a strict and rigid set of rules. And this can be quite a shock to your corporate culture. Because these methods start to tear up the fabric of the organization chart and break down existing silos within the organization.
For example, what does it mean today to say that you work on the ‘Business side’ if you don’t understand the technical delivery? And if you work on the ‘IT side’ but don’t understand the underlying business, then you’re also somewhat redundant. So the water is getting somewhat muddy so to say. While there are certainly specialist roles in agile teams, the whole practice calls for a tight and disciplined integration of Business and IT that is still missing in so many organizations. Now, I am not knocking the whole “Digitalisation” concept. Despite the lack of a clear definition, it has prompted organizations to take a step back and reexamine their core business in light of the transformational shift in technology in recent years. Concepts such as understanding the “customer journey” and reducing “friction” can be extremely helpful in improving the competitive position of the business if they are backed by a comprehensive strategy. But it’s not the strategy per se that will get you there. It is the integration of your business and IT teams fighting towards a common goal with the implicit understanding that the goalposts may shift many times during the journey. I had a look again this morning at the 12 rules from the Agile Manifesto published back in 2001. While so much has changed during that period, I think the rules hold up extraordinarily well.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
You could do worse than continuously reexamine these rules in your own organization and I’m sure you’re on the right track regardless of the industry jargon.
