“Transformation” – a thorough or dramatic change in form or appearance – has been going on as long as society itself. AI, blockchain and other innovations of today are, at a basic level, just modern iterations of the stone, copper and iron tools our forebears put to work millennia ago.
In software engineering we’re very much in the throes of our own transformation. For businesses aiming to grow and prosper in the digital economy, the stakes are similar: get it right, adapt or die.
Accelerating technology advancements over the past two decades create an environment of continuous disruption. Business leaders at big, established enterprises, can’t afford complacency. Nimble, digital upstarts are lurking right around the corner, and many large companies struggle to keep pace.
Robust software is at the core of the agile, digital business, which means we have an existential imperative to figure this out and tackle several pressing questions: How is software engineering evolving toward “modern” software engineering? What have we learned from others’ attempts at transformation? What are the major challenges and risks?
In transformation conversations with companies, I like to start with a different question: What is your objective? Reduce costs, get products and services to market faster, or something else? We’ve seen five distinct approaches to transformation that vary in terms of time and effort invested, “disruption” to the business and more.
The following are brief summaries of each:
Approach 1: Testing Automation
Actions: Automate tests, only a few manual tests remain; there is no automation of software delivery and no introduction of quality engineering practices.
Duration and degree of disruption: Two to three years, with “minor” disruption.
Bottom line: Limited impact to the business. You may see quality and productivity improve somewhat, but that’s about it (agility, employee engagement and speed won’t change). This is because it’s impossible to improve quality without addressing it up front – when the code was developed (through quality engineering).
Approach 2: Agile Transformation
Actions: Introduce an Agile + Scaling framework; there are no changes to the software delivery process, no introduction of quality engineering and no testing automation.
Duration and degree of disruption: One to two years, with minor to “medium” disruption, with no major organizational changes,
Bottom line: Similar to Approach 1, impact of Approach 2 is very limited. It’s difficult to achieve product agility when the engineering process is mostly manual. Still, many companies choose to go this route, as it doesn’t require a lot of up-front investment and doesn't produce major organizational “earthquakes.” Frankly, Approach 2 is dying out.
Approach 3: Software Delivery Automation
Actions: Introduce software delivery automation and testing automation, as well as quality engineering practices, though some manual steps remain. Also, some cross-functional teams may be introduced.
Duration and degree of disruption: Two to three years, medium disruption.
Bottom line: Approach 3 is a significant step in the right direction. You avoid earth-shaking disruption to the organization and you can get it done over a long period of time with relatively small investments. Business impact is limited because you don’t introduce changes to the product development process (Agile/Lean). Still, Approach 3 can be a big enabler for Agile/Lean.
Approach 3 is where most companies are today. Until about two years ago, many were on sidelines, watching the “pioneers” try first. Now, we’re seeing a gold rush into this form of transformation. It’s not super-complex, but not super-easy, either, and you need to invest up-front and be ready to break culture barriers. There may be some pain initially, but benefits will follow.
Approach 4: Engineering Transformation
Actions: Introduce and Agile + Scaling Framework, software delivery automation, testing automation and quality engineering; some manual steps remain and some re-architecture may be required.
Duration and degree of disruption: Two to three years, with medium disruption.
Bottom line: This is the best approach for a company aiming to achieve speed, productivity and quality without major organizational earthquakes. The speed you gain doesn't allow for Lean Startup level of agility but improves it significantly over the baseline. This approach is as far as many engineering organizations go because the change is kept within the technical organization and business is not involved. But if it’s faster software deliver you’re after, this approach gets the job done.
Approach 5: Enterprise Transformation
Actions: Wholesale decentralization and re-organization, including full automation of software testing and delivery, introduction of quality engineering and Lean Startup practices.
Duration and degree of disruption: One to two years, with “major” disruption.
Bottom line: This approach appears to be the “nirvana” everyone seems to want. However, there are trade-offs in terms of utilization of people and overall efficiency. Simply put, we’re talking big, company-wide change. Very few companies are attempting this.
A company’s survival may be on the line, but Approach 5, if done right, can save the day. Whichever approach you choose, it’s important to give it careful thought, take your time and do it right. Once you get started, remember: you’re all-in, only limited by your imagination. Indeed, how big can you dream?