Can the Agile Model Help a Rigid Business?

Posted: 07/06/2018 - 08:41

Is Agile for everyone?

Conventional wisdom has it that Agile product development works only in business cultures that fully embrace the methodology’s principles of responsiveness, speed and focus on business requirements. If you’re not all in, the thinking goes, don’t bother.  

That’s a discouraging message for large enterprises struggling to modernize outdated legacy systems and overcome organizational inertia and resistance to change. Specifically, if the businesses least suited to Agile are precisely the ones that need it the most, how can they hope to close the competitive gap?

The good news is that Agile needn’t be an all-or-nothing proposition. By embracing Agile concepts of simplicity and business collaboration, and by targeting a clearly defined functional scope, even the most sluggish enterprises can move the needle and drive value from the Agile model.

Simplicity and Business Focus

Key Agile principles can be summarized as follows:

  • Customer satisfaction as a top priority
  • Ongoing and close collaboration between developers and business users via face-to-face communication
  • Frequent version releases and openness to changing business requirements
  • Commitment to continuous improvement
  • Simplicity as a virtue

Experience shows that organizations able to adhere to these principles achieve significant benefits. However, many businesses have been frustrated by their Agile experience. Having failed to realize value for either internal users or external customers, they’ve concluded that either they were doing things wrong or that the model was flawed.

Today, the viability of the Agile model has largely been proven by the marketplace. As such, businesses are focusing on how to effectively implement Agile; specifically, through the ability to leverage an Organizational Change Management (OCM) program to transform both operations and mindset.

Finding the Sweet Spot

Finding the appropriate level of scale is critical to Agile’s success; that is, the sweet spot of adoption is to be focused enough to be manageable, yet broad enough to deliver significant impact. In driving Agile’s maturation, practitioners have focused on developing mechanisms to enable increased scalability and extension of Agile principles across a business organization.

The basic unit of the Agile model – the interdisciplinary team or pod – typically comprises members focused on specific tasks such as QA, testing, configuration and backlogs. Productivity at this foundational level is relatively easy. The challenge is that multiple teams or pods – while individually productive – are not designed to work together, and therefore aren’t necessarily contributing collectively to an end-product, application or business objective.

Climbing the Ladder

The “scrum of scrum” component of Agile addresses this disconnect somewhat by identifying common tendencies and shared workloads between teams. To facilitate the deeper level of integration needed to build an application, the program level of Agile – powered by methodologies such as Lean and Extreme methodologies – enables the distribution of work among multiple Agile teams in a concerted manner.

The next rung on the Agile ladder involves the stitching together of a set of program-level solutions to create portfolios and value streams that address business-level objectives for a given profile of users.

The Burden of Legacy

Traditional businesses seeking to become nimbler and gain a competitive edge through Agile are often hampered by their existing operations. The problems start at the top – with outdated legacy systems, spaghetti-code applications and mismanaged M&A integrations – and cascade down through the details of software lifecycle development practices. In such environments, keeping the lights on is the top priority, while the idea of driving transformation is barely on the radar.

The challenge is compounded by the siloed nature of most traditional business organizations. Development work is conducted in isolated towers, disconnected from any product, application or value stream. Rather than aligning deliverables to business objectives, technical teams focus on – and are measured by – their ability to produce discrete functional components. Figuring out how those components contribute business value becomes someone else’s job.

Introducing Agile teams into this type of environment only provides the dubious benefit of being more efficient at creating disjointed technical components and additional layers of complexity. Absent a “super silo” to oversee the work of disparate, unsynchronized teams, the task of integrating Agile becomes monumental.

Defining a Value Stream

To avoid this conundrum, traditional businesses should take a pragmatic approach and recognize that an enterprise-wide Agile culture can’t be built overnight. A key starting point is to identify a potential value stream within the business that might lend itself to an Agile approach. The part of the business that will be the focus of transformation efforts should be separated from the parts to be maintained as is. Whether it’s labeled a bi-modal approach or a “run the business” versus “change the business” model is irrelevant; the key is to identify the scope of the strategy and to quantify the adoption rate.

An example of a value stream in a traditional business might be a B2B order management system. In legacy environments, such systems are typically characterized by multiple platforms, outdated mainframe-based applications and chaotic, ad hoc processes. That said, by scoping the initiative to focus on a specific set of functions, a business can efficiently apply Agile at a team, program and portfolio level. Put differently, by tackling silos one at a time rather than all at once, a business can use Agile to achieve value with a minimal level of disruption and chaos.

Building an Agile Culture

The idea of “less is more” is key to Agile. Enterprises that start small and focus their energy on specific outcomes can achieve measurable value. Moreover, the experience of initial efforts can be leveraged and extrapolated across the enterprise, resulting in the gradual development of an ingrained Agile culture.

Although I know the rule is to write out things under ten and use numbers for those over, I think it looks funny to do it that way when the number is a small-double digit number like ten and would prefer to be consistent.




About The Author

Jaime Palacios's picture

Jaime Palacios is Vice President of Digital Technology and Innovation at Softtek, a global IT service provider. As a passionate “Agilist,” Jaime applies more than 20 years of industry and technology experience to help Fortune 500 clients benefit from Distributed Lean-Agile and DevOps approaches.