Being an enabler of Enterprise Agility

Several organizations have adopted agile, such that today an agile approach is ubiquitous. Since the Agile Manifesto was published in February 2001, agile software development practices have come a long way. However, there is still some debate on the application of agile in distributed offshore teams as it appears counter to agile principles. There are additional challenges within companies because agile teams exist within the context of an organization that may have a limited or diverse understanding of agile, and therefore its ability to support it - the money simply doesn't work like that. Furthermore, an agile approach can encompass a wide range of interpretations from something that is closer to "pure agile" as per the agile manifesto to something cynics might describe as "waterfall with stand-ups". The resultant solution to this challenge is in adapting agile that works within the Enterprise, with distributed teams - Enterprise Agile.

Why would we want to make agile work in the enterprise?

From a team building perspective in a talent arms race, it’s not so easy to engage a development team right now if we describe our new Whizzbang project as a Waterfall Project. For enterprises that want to scale operations on an on-demand basis increasingly can only achieve that through engaging offshore partners. These aside the most important reason that we need to be agile is because this enables us to rapidly respond to the challenges faced by client organizations. Our clients need to behave with the dynamism of a start-up within a context of risk and compliance. We might further consider a wider definition of Enterprise Agile in the context of being an enabler for clients in the wider enterprise sense.

What are the challenges?

We need to recognize that the application of any methodology at the project level is dependent on many factors, both internal (within the agile development team) and external (outside the agile development team). Some of the internal factors that we may wish to consider are the nature of the project - are we doing product innovation, an integration project or a clone project? What is the maturity of the team? Some of the external factors that we may want to consider are to what extent is the product owner aware of the agile process, what’s the agile maturity of the organizations.

Without such considerations there is a danger of falling into the trap of believing that all agile projects are the same, when they are clearly not and indeed the "devil really is in the details".

The challenge is moving beyond commoditized deliverables underpinned by homogenized processes to deliver the real value as an enabler of business agility in the wider enterprise sense. For development teams Enterprise Agile is an opportunity to move beyond a slave to methodology mentality and develop real pragmatic solutions to deliver business value. For organizations, it’s an opportunity to build on excellent foundations and to build a delivery model that works at scale. We would all do well to put our thinking hats on and understand that we might need to be pragmatic, and even adopt something that looks less agile when circumstances dictate.