Can your integration team really use agile?

Other than wondering how to manage integration dependencies, the most frequent question I hear during the software evaluation phase is about the applicability of an agile development process to an integration team.

Of course! It’s just a little (maybe a lot?) more challenging than the product configuration tracks. Here’s why:

  • The scope of the integration work is mostly dependent on other groups in the company, as well as third-party software or service vendors;
  • The program in general, and the integration track in particular, have little to no control over what development methodologies these other teams use;
  • It’s most likely that the other teams are in business-as-usual (otherwise known as BAU) mode, with little capacity or budget for changes; and
  • Many integration themes (e.g. think general ledger, statistical reporting, data warehouse, etc.) are large chunks of work, which can’t be developed, documented and unit-tested within a 2- or 3-week sprint

Now that I’ve sufficiently scared you, let me explain how you can deal with all of these challenges using agile principles.

Despite the direct lack of control over these teams, you can agree during your project inception on a few items that go a long way to an on-time, on-budget delivery.

Definition of done

Before you begin, it’s important to agree on what the definition of done is. It seems obvious but you would be surprised at how many development teams overlook basic expectation-setting. This list can vary across projects, but usually includes:

  • Code which has been fully implemented and checked in
  • Unit tests with a minimum code coverage level
  • All appropriate detailed design documentation

Milestones

Modern software interfaces have different levels of maturity. One simple definition might specify (1) the operation and interface definition itself, (2) a working interface that returns mock data as a response, (3) that same interface with the ability to accept real data and return a non-mocked response, (4) the interface meets the definition of done and is ready for end-to-end stabilization testing.

Agreement on these kinds of maturity milestones will go a long way to de-risking your project. Any two teams, following the same timeline and ashared set of milestones, can move forward with their respective implementations. Each team is then empowered to schedule work as they see fit, with the methodology they prefer (or is mandated by their department, of course.)

Splitting work into sprints

The basic agile principle of breaking down work into smaller pieces can apply to types of epic user stories mentioned above. Most of this should be done during inception, but during sprint planning the team can further refine the tasks associated to these monster stories.

With some common sense and a few of these agile principles, your integration team can realize all of the benefits as the rest of your program.