A lot of the work I’ve done over the years fits within the realm of what’s known as Digital Transformation, which Salesforce summarizes as:
Digital transformation is the process of using digital technologies to create new — or modify existing — business processes, culture, and customer experiences to meet changing business and market requirements. What is Digital Transformation?, Salesforce
For me personally, this has broadly fit into three categories:
In the process of doing this, however, I very frequently run into the following issues:
Years ago, to be successful in these environments, I would lean hard into what’s called Agile Transformation for organizations struggling with these issues. The folks over at Aha! define Agile Transformation as…
…the process of shifting an organization to agile ways of working. This means applying the philosophy behind agile software development to teamwork, collaboration, processes, and measurement. Aha! - What is agile transformation?
I’d start with some scrum training, and maybe encourage a few folks to get certified. We’d build out a backlog and start the scrum ceremonies. In the end, we would deliver some good software and sometimes some not-so-good software. Some organizations would walk away being more agile and others kept on with business as usual.
The problem with Agile Transformation on its own is that Agile has mostly been driven by and for software engineering teams. At the end of the day, forcing teams of designers, content and marketing folks, and customer success teams to adopt strict Agile practices is like using a hammer to crack an egg. With Agile’s focus on efficient output, this can be a very tough pill to swallow for product and design folks who are more focused on solving problems for users and customers. It also assumes that marketing teams, customer success teams, and data teams don’t have perfectly good and nimble workflows of their own that are just fine for getting work done efficiently.
Continuing down the hammer cracking the egg thread… I’ve seen too many software teams get dogmatic about Agile practices, dig into them, and insist that everyone else is doing it wrong when deadlines are missed or deliveries fall short of expectations.
On a more positive note, Aha! goes on to say that Agile transformation requires three areas of transformation:
What I like about what Aha! has to say about Agile Transformation is that it must be rooted in “Data transformation” for an organization.
…the engineering team helps store, serve, and analyze data for the entire organization. Without these efforts, the organization simply cannot transform. What is agile transformation?, Aha!
Why is this? Because without data, product, design, and customer success, teams can’t know if the decisions that were made created the outcomes they wanted. Agile transformation can increase output. Nothing wrong with being more efficient. But focusing only on efficient output is not going to give your organization the transformation you need. It risks making teams work very efficiently on the wrong problems, becoming even more siloed, and even back-peddling to old waterfall practices.
Enter Business Transformation.
Business transformation isn’t tied to any specific software development methodology like Agile. In fact, it’s pretty vague in meaning by itself. It can include some or all aspects of Agile Transformation — digital, data, and solutions — but Business Transformation examines all aspects of the business. David Cruise over at Change Associates puts forth a definition that I mostly like:
Business Transformation is the process of fundamentally changing the systems, processes, people and technology across a whole business or business unit, to achieve measurable improvements in efficiency, effectiveness and stakeholder satisfaction. As such, a business transformation project is likely to include any number of change management projects, each focused on an individual process, system, technology, team or department. What is business transformation?, David Cruise
I like this definition because it includes an emphasis on measurable improvements to stakeholder satisfaction. I’d refine it a little to specifically say:
As David points out, there is little consensus on what specifically Business Transformation is, so to make sense of this, let’s dive into what problem or problems Business Transformation aims to solve.
In 4 Types of Business Transformation, Harvard Business Review created a nice matrix that illustrates four categories of problems a business may encounter where Business Transformation would be used:
The article defines the four types of transformation organizational leaders use for each of these situations: Slow-Motion, Sprinted, Negotiated, and Hijacked Transformation.
What I like about the HBR approach is that it shifts the focus of Business Transformation from being something radically disruptive done reactively to fix problems towards proactively building a playbook for doing business in the rapidly evolving world we live in today. It empowers business leaders to invest in playbooks for each of these types of problems so that they can make the best decisions for evolving their business.
Well, that’s it for now. Thanks for going on that journey with me. Does this resonate with you? If so drop me a line.