FT

Agile for the Enterprise

Monday, 6 June 2022 01:54 -     - {{hitsCtrl.values.hits}}

By Asanga Nugawela 


One of the gravest mistakes of digital transformation is applying the same flavour of agile practiced at startups to enterprise organisations. Applying this same flavour – often, results in failure. Why? An enterprise is a company with a well-established business model. In short, they had already identified ‘how to thrive’ long before agile became an accepted practice. However, a startup is a company in their infancy and still looking for a product-market fit, operating with urgency to be agile and, to find a suitable business model before funding dries up. The paradigm that the old and big lead the new and small no longer holds true. Hence, for an enterprise, past success is not indicative of future results but the ability to adapt and reinvent is.



Need for speed

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

Agile was born in the software development field, but its roots can be traced to a few decades ago through advances in lean manufacturing. With history repeating itself, distinct manifestations with similar patterns can be seen.

Computers, for example, began with large mainframe machines and a user at a remote ‘dumb terminal’. Thereafter, it was the reign of personal computers and laptops. Today, look how far we have come to an era of advanced cloud computing though, not the same as mainframes, however, the same analogy applies where the workload has shifted to remote machines. 

Similarly, software development in enterprises began as an in-house operation. In the past, every organisation developed their own key software applications. Headway occurred, when an enterprise would purchase a software such as an ERP system and configure it according to their needs creating Commercial off-the-shelf Software (COTS). 

However, the rapid evolution of computing power and the pervasiveness of the internet has led to enterprise software being tightly coupled with an organisation’s core business. Hence, regardless of the business domain, software has become a core-competency for every enterprise. Currently, most archaic business models and processes are optimised 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. Therefore, most enterprises are now moving away from COTS for core business functions and developing their own applications to stay ahead of the market. Thus, we need to look at ‘Agile for the Enterprise’ in the backdrop of this transition. 



Closing the gap

Agile was originally meant to facilitate challenges arising from developmental initiatives, managing multiple functional departments to better serve customers ensuring a quick turnaround. However, agile processes may not help if an organisation is overhauling products and services every five years. Rule of the thumb is agile works well in businesses where output results from modular tasks or where products are made up of parts resulting in bottom-up innovations built on practical experience with customers. 

Looking at some frequent challenges faced by enterprises when implementing agile processes at their workplaces - a common phenomenon at the onset of adopting agile at an enterprise is the existence of ‘Dual Organisation’; where hot new businesses are run with agile teams while traditional functions that are left out of the action. This compromises the goal of a holistic transformation resulting in short-term gains, and detrimental to an organisation’s culture in the long-term.

Another pitfall is senior leaders articulating ‘how’ to innovate where they are only required to guide on ‘where’ to innovate. The whole premise of agile is to guide self-governing teams in finding their way around the problem, not enforcing the solution. As business leaders, our duty is to trust and empower teams to develop the right solution. 

A perennial problem at any enterprise is friction between the business and engineering teams. With engineering usually the front runner for adopting agile processes and business teams not in sync, further exacerbating discord and conflicts when implementing agile.

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



Being open to change

Building agility across the entire value chain of a business is an arduous task. Hence, divisions such as IT and Engineering are shaped agile while traditional functions such as Finance, HR and Sales continue to operate unchanged. This is unavoidable as organisational transformation should not be implemented impacting all business functions simultaneously. However, the functions that are not reorganised into agile teams must at least operate with agile values: learning from failure, being obsessed with speed, keeping engineers closer to customers and assigning problems, not tasks enabling all functions within the organisation to communicate fluidly. 

For instance, annual budgeting, which is a traditional exercise can be complemented with a venture capital-like funding approach where opportunities are funded to purchase options for future discovery. 

However, the most fundamental shift should happen in our minds. We must move rapidly from merely practicing agile to a growth mindset. Leaders themselves have a pivotal role to play by being agile. Rather than being directive and top-down driven, leaders must be comfortable in not obtaining all the details in advance. Instead, they should set priorities and separate the journey of achieving necessary outcomes into small steps that can be paused, turned or halted at any time. 

The reason for implementing agile at enterprises is to make disruptive innovations feel less disruptive and more like business as usual. Considerable attention is given to business headlines in the media about Silicon Valley giants disrupting the world. Business models and companies such as Uber and Airbnb have become omnipresent. However, there is hardly any attention paid to how legacy businesses have disrupted themselves. This is where enterprises must realise the pace of cannibalising themselves and continuously innovate to challenge the start-up mindset. 



User learning curve

A common mistake made by many hopping onto the agile bandwagon is to believe that planning is completely redundant. The misunderstanding stems from misinterpreting the Agile Manifesto’s “responding to change over following a plan” to “not having a plan at all”. Such thinking is disastrous to an enterprise as large organisations require planning at every stage. Unlike start-ups, enterprises are always under pressure to deliver results. Over the past 20 years, we have been constantly inundated in agile thinking, where we believe that even an iota of planning is against the principles of agile. 

This is totally false. Planning is all about ‘where’ to arrive. An organisation can easily get sidetracked without deep diving into expected outcomes (growth, profitability) but pursue trivial outputs (number of new products, lines of code). There is nothing worse than your teams iterating over an over to create an output that is strategically unimportant. Agile is all about being flexible in the journey to achieve the desired outcome. 


(The writer, Director – Delivery at Sysco LABS, has over 15 years’ experience in leading all aspects of technical projects from start to completion and successful delivery to global clients. Asanga has extensive experience in Product Development roles and in pioneering Agile practices and Lean Startup thinking for enterprise organisations. He possesses an MBA from the Postgraduate Institute of Management and a B.Eng. (Hons.) in Electrical & Computer Systems Engineering 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