A simple approach to break IT transformation myths


I published a short quizz in July 2020 on Linkedin to have a quick overview of the way my clients and partners handled the COVID crisis. I published it in french (because I’m french, as well as a large part of my network. My apologies for the errors you’ll notice ^^), with a simple goal : have some fun and help to set the record straight about IT transformation.

I had read so much nonsense and mistakes about IT agility and transformation during the lockdown… So I’ve been very solicited to help :)

The concern I had to deal with was that my clients come from a large variety of businesses, so I had the idea to guide them all with a simple method : help them to ask the good questions, consider their context and avoid details for now.

The quizz had fifteen assertions, for which you scored a point if you agreed or understood the assertion. Here they are with a simple explanation that may help to consider the change :

1 —DevOps culture and agile methods are NOT the “latest flavor-of-the-week”. No need to dig the complete history of agile approach, you just have to keep in mind that “agility” was popularized by the Manifesto for Agile Software Development, published in 2001. I said “popularized”, because many methods existed before the publication of the manifesto, and were used in early 90’s ! Cool fact : SCRUM celebrates its 25th anniversary this year ;)

The DevOps culture “officialy” raised in 2009 (at least its name), but the principles of automation, continuous integration, continuous delivery, change management, etc. find their source in several methods and practices including Lean philosophy (Toyota Production System), created in 50’s and used/improved/adapted since then !

I’ll write a more detailed story about “Agile world” this year :)

2 — Complexity does not induce difficulty. For (too) long, people considered that building complex systems or organisation was a proof of “mastery” (and helped to be a “necessary person” for an organisation…). And because of this nonsense, we’re facing the most amazing consideration in transformation : “It’s difficult to make it simple.” There’s no difficulties to change a system or an organisation, there’s only complexity to manage its interactions, dependancies and evolution. Difficulties may stop the change initiative, complexity help to identify the best way to change.

3 — Je connais la différence entre (I know the difference between) transformation digitale et transformation numérique. This one is a special “frenglish” joke. We’re all talking about “digital transformation”. In french, the correct translation is “transformation numérique” (numérique relates to digital technologies to be simple), but a looooot of french people (who probably wants to be cool by using english words…) are using “transformation digitale”… And “digital” in french relates to… fingers ! So each time I hear “transformation digitale” in french, I see Edward Scissorhands… (Or Freddy Krueger in that case…)

4 — You can’t improve what you can’t measure. That’s one of my conviction. I borrowed and modified this quote from Peter DRUCKER (“If you can’t measure it, you can’t improve it.”). It doesn’t only stand for business mangement, it works for everything. The most common mistake I’ve seen was transformations or initiatives with targets, but with no starting point, because “we’re agile so we can adapt during the trip !”. My poor little heart is bleeding…

5 — Creating value is not just about generating financial profits. Probably the most difficult concept to communicate. There’s so much to explain about “value”… You just have to understand that money should be the consequence of creating value, but not the target. Security, compliance, mature change management, services capabilities, improved processes must be considered as value. Money could come after, because you’re safer, faster, stronger and/or more adaptive. And value is different for each of your stakeholders. Don’t get lost along the way.

6 — The rigor expected in project management does not prevent agility in its implementation. This is a sad observation… Many organizations experience the worst difficulties in managing their projects effectively, and think an “agile transformation” will solve everything… And when they try to transform themselves, they keep their bad habits and inadequate processes. Some of them do not understand the difference between a project approach and a product approach, and waste time and energy to create a home-made framework that essentially results in the worst of the two approaches. A transformation should be considered like a project (even a programme), but be based on a framework/method that could be easily adapted in the specific context of the organisation and provide the first step for agility. And we all know that a project, no matter how well prepared, is subject to change :)

7 — Organizational culture is not contractualized, it is built. Many companies adopted outsourcing excessively, especially for IT, thinking that “If you pay for it, you don’t have to explain what are your expectations.”. It’s a big mistake to believe that a “supplier” completely understand your culture, your values, your organization. In the short term, this often causes delivery problems for the expected products/solutions. In the longer term, quality disappears, collaboration collapses, and worst of all, the company no longer controls its products and services. It is an painful exercise to find the right balance between a DIY culture and outsourcing, but this is a point that must be adressed !

8 — Ignorance is the easiest evil to fight: you just have to learn. And I will add that we must make sure of what we know, and identify what we do not know. I am convinced that knowledge and learning within companies are the strongest levers for growth. But I also know that there are (too) many excuses for not training/supporting employees… This is one of the reasons why more and more employees are leaving their company, and not just for a promotion story, no… Many people want to grow and support their company. If you give them up they will go. Simple and dangerous.

9 — It is better to BE agile than to DO agile. (but the two options are complementary ^^) And if you don’t know the difference, you have to understand that “doing” Agile is focused on practices, methods and iterations but at the organization level (and let’s be clear : Using ZOOM doesn’t make you an agile business !). Being Agile is more about a mindset, personnal or collective. This has a strong impact on the appetite and the relationship to changes. You want your organization to embrace change, innovation, and learning ? Take a look at the behavior of your employees first ;)

10 — I know the difference (and the link) between data and information … Information is data delivered with an interpretation rule. And the interpretation can be processed in artificial ou natural langage. Mastering your information system means first mastering your data. I’m not joking :)

11 — … and that’s why I control the evolution of my IS ! Well, hum… And that’s why we waste time and money because we focus on information without knowing its origin and purpose… And it becomes very complex to provide and maintain efficient and flexible architectures ! Because of this lack of awareness, we have to deal with Frankens-IT-ein’s creatures.

12 — Identifying the SPOF is good. Eliminating them is better. You may think “It goes without saying !”. But I know many companies who think they have a great mastery of their IS just because they have identified (and only identified) a bunch of SPOFs (yep… They have several … On the same system …). A well identified SPOF must be the trigger for transformation.

13 — Risk management is not about finding reasons not to do, it’s about finding the safest way to do it. Assertion that only makes sense if your company manages risks (or not…) :) It’s funny to see people turn pale when you say the word “risk”… Too many companies (awkwardly) associate risk with threat. And only see the risk of doing, never the risk of NOT doing… You have to understand that risk is an uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives, projects, programmes, etc. Risks can have either a negative or positive impact, they can be threats or opportunities ! See ? It changes the game.

14 — Prioritization and organization problems are solved with the simplest tools in the world (MoSCoW, Eisenhower Matrix, Pomodoro, etc.). Stop fussing around unnecessarily ! The main problem has never been prioritization, but understanding what to do and why ! What’s the point of setting up an artillery battery (and a regiment to decide) just to know if you want to drink water or milk? And for the love of God / Yoda / Cthulhu / French Wine (cross out the unnecessary), don’t try to complicate simple tools! Just use them !

15 — I did not go to Google to understand assertion 14 😊 The bonus assertion :) Because there is a difference between knowing that there are simple tools and knowing how to use them.

The feedback was very interesting, the vision of some people was obscured by the grind of the work, but there was a real awareness of the stakes of a properly considered transformation. I’m currently working with some of my clients who have understood and admitted that is necessary to be well supported for this kind of initiative.

I hope this entertained you and helped you take a step back from approaching a transformation. See ? It’s not just a tech story :)

Take care !

Originally published at https://www.linkedin.com.

IT consultant & trainer, DevOps Evangelist, Agile wizard, organizational changer and trouble maker :) Knowledge is only valuable if it is shared !