Managing Systems Integrations using an Agile approach, everyone’s favourite topic!

I don’t normally post on here, but I’ve got a bit of time on my hands at the minute, so I thought I’d give it a go!

Everywhere I work there seems to be a desire to develop software using an Agile approach, but the reasons for this are often flawed. I’ve worked on quite a few system integration projects and traditionally these are only approached using a Waterfall delivery because of the nature of the work. Business Requirements and the systems architecture determine what integrations will be required on a project, so it is easy to see why the traditional requirements, design, development, test and then implement approach would be used.

That is a view I shared until recently, as on my last project there was a desire from a programme level to progress integrations as early as possible. With the help of the development manager I managed to adopt managing integrations using an Agile approach (Kanban) within a waterfall governed programme. I’m not an expert on agile methodologies, but I know enough to understand what works and what does not. The 5 key things that I learnt from this are;

·        Use a quick proof of concept to overcome specific challenges, e.g. a new type of application or protocol to integrate with. These should be scheduled early, so that lessons can be learnt and must have success criteria to measure outcomes.

·        Create a definition of ready, this is the essential information that is required in order to kick off the development of a specific backlog item. Typical items that are listed on an integration focused Definition of Ready are: samples files, data contracts, transformation analysis, single point of contact of relying backend application.

·        Have a cross functional team, consisting of business analysts, developers and testers. Also, where applicable, involve relevant subject matter experts from business or technical teams (HR, Finance, Java, Testing, etc)

·        Introduce spikes to check connectivity. Integration is all about connecting backend systems seamlessly with each other. Setting up a new connection can be a real hassle, due to reasons such as setting up firewall rules and security and user account settings. So doing this work early means that when the ‘real’ development work starts, the connectivity has already been proven.

·        Focus first on getting a thin slice of an integration working end to end, so that at least some data can be exchanged between the source and target systems. This proves that data can be exchanged successfully. You can then complete the data contract and add security and housekeeping requirements to build the complete integration.

I think that being able to walk away from a project with learning such as these that can be applied elsewhere on future projects and is key for my progression as a project manager and my ability to manage these types of project in the most effective way.

Anyway, that’s my view. What about yours? Is there anything else you have found from your experience?