Avoiding Change Game

Integration project, by nature, have quite a lot of parties contributing to project. Customer has User Stories, several software vendors provide interfaces to their system and integrator is knitting all this together. If either Customer or some other party than integrator changes user story, business requirements, test material, interface definitions etc. integrator is facing a change. Typical sources of changes for integration project are

  • Process level details change after first iteration – all details were not known at the beginning of sprint for all Sprint Tasks. This might be intentional – then also costs can be estimated. Sadly, quite often these new detailed requirements are surprises for Customer as well and this initiates change management process.
  • Interface details change during Sprint. Quite often we’re integrating systems that are under construction – changes to system interface, that have already been integrated in earlier sprints, create changes to these integration for next sprints. Technically this is not a problem, but have an impact on costs and scheduling as new changes are presented to backlog.
  • Low quality test material leads to a manual or automated tests that does not cover enough business cases. Typically integrator is missing test material for all variations of possible inputs and outputs of systems. For Test Driven Development (TDD) these are mandatory material for successful development and high quality.

How to avoid these pitfalls in a integration project? One might start babbling about popular topics like lean integration, good project management and so on. I’d like to keep it as pragmatical as possible:

  • Acceptance Test Driven Development with mutually agreed Acceptance Test Cases even before implementation of test automation starts. This greatly reduces amount of misunderstandings of business level functional requirements.
  • Pay attention to details;
    • exact mapping charts with mapping rules
    • variable test material
    • clearly stated business logic rules and especially their exceptions
    • non-functional requirements
    • interface definitions from other suppliers
  • Implement and follow integration architecture plan. Good integration architecture plan contributes ready implementation patterns, non-functional requirements and best practices tailored specifically for your company’s need.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s