When agile is not a natural fit

For a while now, I've been leading a team in a situation where textbook agile practices aren't a natural fit. My company, IP Commerce, has built a platform to enable electronic payments. Applications (built by third parties) connect to our platform to gain access to a variety of payment services such as credit card processing, electronic check processing, and e-commerce services such as PayPal. My team is responsible for integrating the various payment services with the IP Commerce platform. Each integration is called an adaptor, which translates messages (transactions) from the IP Commerce format to the service provider format & protocol. Why is it that this type of development doesn't easily fit into the typical agile model?

• The scope of each adaptor is essentially fixed
• Each adaptor must be certified before it can be deployed
• The duration of each adaptor project is 6-12 weeks

Let's examine each issue in more detail.

Scope
Each adaptor translates messages, and to accomplish useful business functionality, there is a minimal set of messages that it must support. For example, in credit card processing, a customer must be able to do authorizations, voids, refunds, and settlements. Without all of those features, it doesn't meet any customer's minimal requirements. The only scope which is negotiable is minor features, such as corporate purchase cards or certain industry-specific features, for example those that support the lodging industry.

One of the core presumptions of agile is that scope is negotiable and features can be prioritized. If 90% of the scope is fixed and all the features (in this case, message/transaction types) have the same priority, the backlog isn't very interesting.

Certification
Agile methodologies, Scrum in particular, assume that a product can be deployed when the product owner judges it to have enough functionality completed. In our case, an adaptor cannot be deployed until the service provider to whom we're integrating certifies it. Not to mention that, as explained above, we need essentially all of the features working before it is useful to customers. This dependency on an external verification process is unavoidable, and unfortunately, it often takes a long time.

Duration
Each adaptor project lasts between 6-12 weeks. Most agile projects I've been involved with before now have been much longer, and have many more iterations that establish the all-important feedback loop and team rhythm.

Adapting agile to the situation
One approach we have tried is to treat each adaptor as a single coarse-grained feature in the backlog. This makes sense because these are the units of functionality that the business prioritizes, but on the other hand it doesn't make sense because agile features (user stories or backlog items) need to be small enough to fit into a single iteration (sprint). That disadvantage is a big one in my mind, so we have decided it's not a good approach.

Instead, we have decided to choose smaller backlog items, which for a single adaptor include a combination of true user-stories (message types and other user-identifiable features) and milestones such as 3rd party certification. In the past, I have been a big proponent of using a consistent sprint/iteration duration. In this situation, however, we've found it to be useful to first identify a concrete objective for each iteration (e.g. complete the first 2 message types, or achieve 3rd party certification) and then choose the sprint length based on the tasks required to achieve the objective - while keeping each iteration to 4 weeks or less.

It still feels awkward at times, but I feel we benefit greatly from relatively short iterations.