Friday, July 3, 2009

Challenges when combining SOA and Agile

For me, both SOA and Agile require deep cultural changes in organizations in order to be effectively implemented.

Usually, many assumptions about using Agile rest on having self-organizing, self-managing and cross-functional teams. This is typically a step away from traditional “top-down” monitor and control approaches to management and “over the fence” requirement/delivery management. Organizations are open systems that require a holistic approach when changing; hence trying to implement Agile locally without taking into account the non-local forces that will impact the agile delivery group could result in frustrations and poor performance. To illustrate this, one only has to think about the manager that wishes to foster agile delivery but must supply the “traditional” project management indicators/elements to a VP (long term estimates/planning, weekly progression, change requests, etc.) for a dashboard.

SOA also requires deep culture transformation. For me, SOA is not about technology (Web Services, REST, etc), its about having a clear understanding about operational processes as well as their segmentation, governance and data requirements. In my mind, in order to achieve a truly effective SOA implement most of the values of Quality Management (or Total Quality Management) must be implemented such as “global interests above local interests”. SOA requires a holistic, cross-functional approach to its implementation and management.

An example of a possible challenging situation that an Agile-SOA team could face is one which requires the team to delivery a list of services that surpasses its knowledge base. In this context, chances are that “over the fence” attitudes will show its face; instead of using a self-contained cross-functional delivery team, requirements gathering will probably be thrown over the fence (because it is usually the hardest) and the SOA team will only manage delivery. This situation creates a potential gap between what is required and what is delivered as well as an “us vs them” dynamic which does not follow the values of Agile. Now, we can also imagine that the team must delivery data-oriented services in which the consuming departments and the producing departments of the data are not the same. In this situation, if the organization is not supporting holistically the values of SOA, the team will struggle deeply with the prioritization of the services when “local interests” pressures build around the task without the capability to manage “global interests”. In this context, SOA adds an extra layer of complexity because even if the team manages to holistically prioritize the services to deliver (holistic planning) they must also manage to get people with potentially no interest in certain data to produce it for another group (holistic delivery). The latter combined with the former requirements-delivery gap and an “us vs them” dynamic can make for a very explosive experience and frustrating.

So in a nutshell implementing “SOA-Agile” = implementing “holistic planning and delivery” which requires a deep change in culture in most organizations… its no just about technology.