Two SCRUM teams develop separate part of a system, including an API for intercommunication between them. Working agile, they would want to be able to turn around fast, "embrace change" - but what about changing the API once defined?
Naturally there will be a higher threshold for changing the API, than for changing the internals of one subsystem. The API represents the only visible part of the "Black Box" that the other party relates to, and changing it influences the other team's work. The nature of an API is to a large intent being a stable protocol.
Being a "dual" SCRUM project, the obvious solution would be adding a minimalistic third SCRUM team to handle the API itself, with representatives from both teams collectively filling the product owner role. A limited SCRUM of SCRUMS, you might say. If done so, the API doesn't necessarily represent a big challenge. In this case the API is defined not to be static.
There may be matters complicating API changes once put into production; Changing APIs would also require synchronous deployment. Now there could be differences in deployment processes: A new version of the backend side of the API may require system downtime and a lot of administration to handle e.g. ongoing sessions, while updating clients could be a walk in the park.
For both teams to be able to profit from actually having an API as a sensible boundary between subsystems, governing the API may be an important issue.
Different possible strategies:
- Require the API to be static and complete up front: A change requests would be handled in about the same way as they would be in a traditional waterfall project - considered a specification or design flaw or at least a new requirement and cost would be billed (literally or symbolically).
- Introduce a versioned API, to allow for flexible upgrades of new functionality. Unless this is planned for from the very beginning, it would not be very different from #1.
- Build flexibility into the API. An SQL based database interface may be considered being a flexible interface, as a column could be added without changing any application or even restarting the database server providing the API.
Published APIs may be extended, but ideally not changed. When using the MS Office COM interface for remoting Word and Excel throughout the 90's and 2000's, you could rely on your application still working with a new MS Office release. To use new features you would need to adapt, but nothing existing would need changing. The MS Project application, on the other hand, changed significantly from version 95 to 98 - indicating at least two things: 1) There wasn't a large API user base, and 2) the product was immature ("...is the 98-version mature yet ?"). The same goes with MS InfoPath, changing significantly in 2007. My conclusion when experiencing these changes was to avoid these products as part of a system - for both reasons 1) and 2).
When talking about APIs today, you would normally think Web APIs. Are there any differences to the mentioned MS APIs? "Yes and no", I'd say. Web applications change frequently, life time may be quite short. Being in front is more important than it would be for an inhouse admainistrative solution, so life cycle could be significantly shorter. On the other hand, the Web API customers would normally have various options and so the API provider would be proportionally afraid to impose obstacles for API consumers. Also, Web API clients may not have a lot of resources to deal with rapid changes. And remember - the old Word 2000 may still be run as part of a system today....
Including data or functions from an external source in your web application requires trust, much like when choosing any product; You assess quality, and you would possibly consider if the product will be serviceable and/or will around for a required life span of your system. Also, using a product or a concept requires investment in knowledge and possibly tools. The relevance of the API is based on usability and trust.
Conclusion: APIs are in their very nature static and the more static the better. Not very compatible with agile methodology ? May not seem so, but if you control both sides of the API it need not be a problem. Also, extending the API is still possible without breaking any deals