Agile for Business | Daily FT

By Asanga Nugawala

One of the biggest mistakes of digital transformation is applying the same agile flavor practiced in startups to enterprises. Applying this same flavor – often results in failure. Why? A company is a company with a well-established business model. In short, they had already identified “how to thrive” long before agility became an accepted practice. However, a startup is a company in its infancy and still in search of product-market fit, operating with urgency to be nimble and, to find a suitable business model before funding dries up. The paradigm that the old and the big lead the new and the small is no longer true. Therefore, for a business, past success is not indicative of future results, but the ability to adapt and reinvent itself is.

Need of speed

Today, most start-ups are either in the software space or businesses powered by a software platform. On the other hand, most established companies engage in non-software activities with software (commonly referred to as IT) relegated as a mere cost center in their back offices. However, most of these established companies are acutely aware that their business models and domains are constantly targeted for disruption by start-ups. In attempts to match a start-up’s inimitable agile approach to disruption, the company with its rigid structures struggles to adopt start-up’s agile practices verbatim, leading to chaotic transformation.

Agile was born in the field of software development, but its roots go back a few decades through advances in lean manufacturing. As history repeats itself, distinct manifestations with similar patterns can be observed.

Computers, for example, began with large central machines and a user at a remote “dumb terminal”. Subsequently, it was the reign of personal computers and laptops. Look how far we have come to an era of advanced cloud computing today, not the same as mainframes, however, the same analogy applies when the workload has moved to remote machines.

Similarly, software development in companies started as an internal operation. In the past, each organization developed its own key software applications. Progress occurred when a company purchased software such as an ERP system and configured it to suit its needs by creating commercial off-the-shelf (COTS) software.

However, the rapid evolution of computing power and the ubiquity of the Internet have led to enterprise software becoming closely tied to an organization’s core business. Thus, regardless of the field of activity, software has become an essential skill for every company. Currently, most archaic business models and processes are optimized through software. In some cases, the superiority of software and IT are the only differentiators between competitors in the same business. In such a situation, it is counter-intuitive to use the same software as your competitor. As a result, most companies are now moving away from COTS for basic business functions and developing their own applications to stay ahead of the market. So, we need to consider “Agile for the Enterprise” in the context of this transition.

Close the gap

Agile was originally intended to ease the challenges arising from development initiatives, managing multiple functional departments to better serve customers by ensuring rapid turnaround. However, agile processes may not be useful if an organization revises its products and services every five years. The rule of thumb is agile works well in companies where production results from modular tasks or where products are made up of parts resulting in bottom-up innovations based on hands-on experience with customers.

Looking at some common challenges businesses face when implementing agile processes in their workplace – a common phenomenon in the early stages of agile adoption in a business is the existence of a “dual organization » ; where hot new businesses are run with agile teams while traditional functions are left behind. This undermines the goal of holistic transformation that results in short-term gains and is detrimental to an organization’s culture in the long term.

Another pitfall is that senior leaders explain “how” to innovate when they are only required to say “where” to innovate. The whole principle of agility is to guide autonomous teams to find their way around the problem, not to apply the solution. As business leaders, our duty is to trust and empower teams to develop the right solution.

An ongoing problem in any business is friction between sales and engineering teams. Engineering is usually the favorite to adopt agile processes and unsynchronized business teams, which further exacerbates discord and conflict when implementing agile.

The best long-term solution is to have engineers interact directly with customers. However, this is easier said than done. The best middle ground is to separate ‘product’ from ‘engineering’ by creating an independent ‘product’ team to liaise between the sales and engineering teams. This will serve as a buffer between the two warring parties until the commercial and engineering teams come together and come to an agreement.

Be open to change

Building agility across a company’s entire value chain is a daunting task. Thus, divisions such as IT and engineering are shaped in an agile way while traditional functions such as finance, human resources and sales continue to operate unchanged. This is inevitable because organizational transformation should not be implemented by simultaneously impacting all business functions. However, functions that are not reorganized into agile teams must at least operate with agile values: learning from failure, obsessing over speed, bringing engineers closer to customers and assigning problems, not tasks that allow all organizational functions to communicate fluidly.

For example, annual budgeting, which is a traditional exercise, can be complemented by a venture capital type funding approach where opportunities are funded to buy options for future discoveries.

However, the most fundamental change should occur in our minds. We need to move quickly from just agile practice to a growth mindset. Leaders themselves have a central role to play in being agile. Rather than being directive and top-down, leaders need to be comfortable not getting all the details up front. Instead, they should prioritize and break down the journey of achieving needed results into small steps that can be interrupted, reversed, or stopped at any time.

The reason for implementing agility in business is to make disruptive innovations feel less disruptive and more like the status quo. Considerable attention is paid to commercial headlines in the media about Silicon Valley giants disrupting the world. Business models and companies like Uber and Airbnb have become ubiquitous. However, little attention is paid to how the legacy companies have been disrupted. This is where companies need to realize the rate at which they are cannibalizing themselves and constantly innovating to challenge the mindset of start-ups.

User learning curve

A common mistake many people make when jumping on the agile bandwagon is believing that planning is completely redundant. The misunderstanding stems from misinterpreting the Agile Manifesto’s “response to change by following a plan” as “having no plan at all”. Such thinking is disastrous for a business because large organizations require planning at every stage. Unlike start-ups, companies are always under pressure to deliver results. Over the past 20 years, we have been constantly inundated with agile thinking, where we believe that even an iota of planning goes against the principles of agility.

It is totally false. Planning is a matter of “where” to arrive. An organization can easily get sidetracked without diving deep into expected outcomes (growth, profitability) but pursuing trivial outcomes (number of new products, lines of code). There’s nothing worse than your teams iterating over an over to create a strategically insignificant result. Agile is about being flexible in the journey to achieve the desired outcome.

(The author, Director – Delivery at Sysco LABS, has over 15 years of experience leading all aspects of technical projects from start to finish and successful delivery to global customers. Asanga has extensive experience in product development roles and in pioneering Agile and Lean Thinking Startups for Business practices.He holds an MBA from the Postgraduate Institute of Management and a B.Eng.(Hons.) in Systems Engineering Engineering and Computer Science from Monash University, Australia. He is also a Certified Project Management Professional (PMP), Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), and a SAFe Agilist.)

Comments are closed.