Digital Transformation…. The Hard Parts
Tech is overflowing with organisations wildly proclaiming how much more digital they will become, how much more agile they will become and how much more customer-driven they will become. But beyond the hype and sensationalism, many transformations fail. And for some strange reason, people are less keen to talk and blog about their embarrassing failures.
Transformation requires a strategic long-term vision, based on an understanding of continuous delivery and matched with an unrelenting commitment to organisational change. And that is hard. Changing people’s beliefs and how they work is hard.
Want to watch this post as a talk instead?
Digital Transformation the Hard Parts — Nick Tune, Lean Kanban France 2016
What I see and hear, over and over and over, is organisations doing what they always have but giving things funky agile names and making cosmetic changes. Project managers? They’re called Scrum Masters now. We don’t do waterfall anymore, but we’ve planned out the next 27 sprints in minute detail. Empowering our teams? Of course we let them put sticky notes on the wall!
But the mistakes I see. Always the same. The same fundamental problems that aren’t easy to solve, but do have tried and tested solutions.
Do any of these sound like your transformation?
Fear of Decentralising Decision Making
Crack-the-whip command and control; often associated with micro-management and huge egos, rarely associated with high-performing agile organisations and successful agile transformations.
It’s a massive commitment to drain authority from the obese layer of middle-management and into delivery teams, but that’s one of the key battles that all of the best agile success stories I’m aware of have won. And conversely, the failed ones haven’t.
Agile is about speed, quality and efficiency. It’s about improving how quickly we learn & deliver value, and it’s about reducing the amount of unnecessary effort involved.
When we hand teams business outcomes and provide everything they need to achieve them — from decision making responsibility to end-to-end technical ownership — we lay the foundations for optimal iteration speed, development efficiency and innovation.
But when we rely on traditional top-down management, we increase the feedback loop and lead times. Greater distance between the people making decisions and the consequences of their decisions. And we hurt motivation — micro-managed people treated as mindless labour aren’t those we associate with high-performing agile teams.
Fear of Changing Organisational Boundaries
To enable autonomy of teams so that they can achieve business outcomes, we need to remove impediments and dependencies. Yet so many organisations are terrified of breaking down their layered organisational silos.
Business outcomes are about delivering value to customers — not adding new columns to a database, or creating an API, or building a web page to call that API. A business outcome is all of those things working together. Yet some organisations simply cannot stomach the idea of flattening their frontend, middle and data tiers into vertical slices of functionality aligned with business outcomes.
If you follow a piece of work from conception to delivery, and it passes through multiple teams, you’re probably doing it wrong.
Handover phases are expensive. They require collaboration and coordination costs. They remove autonomy. Instead of a team having clear goals and everything they need to achieve it, they waste lots of time in meetings, find themselves eyeball-deep in politics and become accustomed to waiting for other people to deliver before their own work can be delivered.
It’s inefficient, it’s a motivation killer and I haven’t seen a single agile success story where silos and handover phases were the foundations for success.
Unwilling to Embrace Continuous Delivery
If you’re talking about transformation in the year 2016 and you’re not striving for continuous delivery, you’re in a very small niche or your transformation is a joke.
Continuous delivery has become the new normal. Lead times of hours rather than months is where the industry has already been for a few years. Continuous delivery helps organisations to deliver faster, more efficiently and with less risk. The only drawback is that it takes time and effort to build up a culture that supports it.
I’ve worked at multiple organisations practicing continuous delivery. I’ll never forget my first continuous delivery love story, though. One-click deploys. Multiple deploys per-day. Zero time wasted on manual regression testing. That experience taught me everything about how IT should drive the organisation and not be a huge anchor that holds it back.
If you cannot add a new text box to an existing web page in a couple of hours, if you cannot turn around a trivial production bug that was raised at 9am before you go home at 5pm, or if you spend hours doing manual testing, you are not even average agile. Those are the minimum capabilities successful agile organisations demonstrate in the year 2016.
Out of Touch With Modern Software Development
A lot of CTOs, architects, and similar roles sit comfy in their beautiful ivory towers deeply disconnected from how modern software development works. Unfortunately, that limited understanding coupled with their ego holds back the entire transformation.
One of the key reasons, in fact, that organisations are unwilling to embrace continuous delivery, is that their technical leaders have not kept up with the industry and do not realise what is possible nowadays.
They don’t understand the technology and how it enables low-cost deployments. They don’t understand the agile working practices that teach us to build quality in like TDD, Pair Programming & code reviews. They just can’t see how all these things fit together to support continuous delivery and agility so they dismiss it or aren’t even aware of it.
They are often the same technical leaders who promote the siloed organisation structure. They are the ones most reluctant to change and least knowledgeable on succeeding with agile — but they’ve been privileged with positions of authority and make all the important decisions.
Fear of Changing People
People in positions of power unwilling or incapable of change are sometimes the biggest barrier to success. But due to their authority, the organisation is scared to replace them or simply does not realise they are the problem.
If top management is incapable of removing these senior people, or promoting people who know how to succeed with agile into positions of influence — what hope is there? Who is going to drive the change, your cleaner?
If you are one of those organisations. Until you have the right people in positions of power, you will be the failed transformation stories we all laugh about at conferences and meetup groups. You will be “that I organisation I once worked for where we did planning poker for 9 months of work up-front”.
Transformation by its very nature is about change. Changing from monthly release cycles to hourly. Changing from big up-front design to continuous iteration and improvement. Changing from top-down management to data and customer-driven decisions. But if you don’t change your uncompromising people who hold power, how will you change any of those things?
Fixing Broken Culture With Technology… and Failing
When organisations are afraid to change their culture — afraid to reshape organisational boundaries and distribute responsibility — afraid to learn modern software development practices and strive for continuous delivery — they instead turn to technology for quick-fix answers.
Indeed, the marketing is oh so seductive: why do all of those hard cultural changes when you can buy a piece of software that can do it all instead?
Your programmers are slow? Don’t waste time investing in your people and how you develop software, replace them with generic rules engines that business people can use. And whilst you’re at it, replace a few more programmers with business workflow tools where you draw a few boxes and it does it all for you.
One day technology will be good enough to replace programmers. One day us geeks will have to learn some real skills. But those gimmick products are the equivalent of get rich quick schemes that make easy money from fools.
If you resort to buying those hyped-up tools, looking for a quick win, looking for an easy way to avoid fixing your broken culture, I feel sorry for you. But I do have some of this magic pixie dust that will come and fix all of your problems, and it comes at a very reasonable price.
You’ll only need me to come and review how you’re using the pixie dust every six months for a small service charge. And I’ll only have to charge you a very small amount to fix it when things go wrong and you have no idea how it works. Do remember that when someone else has some other pixie dust you’re stupid enough to want to buy that you’ll be locked into my pixie dust. And one last thing, every year you’ll need to give me a bit more money to upgrade to the latest pixie dust. If anyone questions your decision to buy my pixie dust, look at them with disgust and say “this is the direction the industry is going”.
By the way, I’ve also got some amazing snake oil that goes with this pixie dust. I’ve already added three bottles to your order.
Outsourcing Core Functionality
Some organisations are quite clever now. They’ve been bitten hard after throwing money at gimmick culture-fixing tools. Now they outsource instead! But being clever, they only outsource to the best consultancies — those who have big “Agile”, “DevOps” and “Digital Transformation” banners splashed across the home page and plasteered all over their blog.
Of course, there are a few tiny caveats; you may spend more time haggling over the price of a change request and debating the quality of the work produced than it takes to develop it; the lead times are in weeks rather than hours; the consultancy is busy working for another customer. But these compromises are easily manageable if you give up on agile and throw your transformation ideas away.
I am highly skeptical of anything that increases lead times and increases collaborative inefficiencies. I am highly skeptical of situations where the development team are not thinking long-term about continuous improvement and how they can better serve customer needs. Whenever I’ve seen outsourcing, I’ve seen these undesirable qualities in abundance.
For an organisation aspiring to be agile, I just don’t see any benefits in outsourcing core functionality or infrastructure.
Throwing money at consultancies is not an inherently dumb idea. But I would strongly advise you to have them work for you; working along side your people and building up your internal capabilities. Vitally, ensure they are not selling you any of their tools and the work produced is owned by you.
