We recently completed our first integration with an external customer website and our e-commerce website. (By “integration,” I mean an API in which we pass configured product data from our site to a 3rd party shopping cart.) What ensued was an interesting learning experience for myself and our group of developers on the project.
Everybody has their own development process
Standards are hard to come by in the web application/development world and the process for managing development projects is certainly no different.
Case in point: We created a technical specification for an API and worked with developers on our own team spanning 3 different time zones. Add on top of this that our technical specification was an “ideal world” document which didn’t account for specific requirements of the external website we were to interface with. This meant further coordinating our simultaneous development of our API with the integration of the API (as we were building it). This essentially equated to “building the plane as we flew it.”
Agile development is great…but falls flat on its face when involving people outside the core team
In an agile software development world, code is written, tested, and released in several mini-stages. This methodology allows for us to be very open, flexible, and speedy with new development on our various web properties.
However, my takeaway from this project is that I would utilize a different approach when interfacing with external developers that are not part of the core team…taking me back to my agency roots when educating our clients about “our process.” What we found is that our process didn’t at all align with the customer’s process for development, testing/QA, and release management. In fact, it caused a lot of tension between the two groups throughout the project — especially in the home stretch.
Where we normally operate in a lean environment with small release gaps and short testing periods, the external party we interfaced with was accustomed to a more traditional waterfall model of building the entire application up front, test all of it at once, and going through several iterations of testing & debugging of all code at the very last stage.
Lesson learned: Provide a visual map of your process and timing
Multiple lessons were learned on this project:
1.) Provide a “site map” of the intended integration. This allows business stakeholders to visually understand where the API “handshake” occurs between the sites. It also empowers the external QA team to understand the bigger picture so they can see which areas need testing.
2.) Provide a map of the major components of the development project, timing on each, and the order in which they will be developed. Seems simple, but when you don’t manage the external developers, keeping tabs on the timeline proves difficult.
3.) Schedule regular daily meetings to check in on status and even if there’s no updates to report, it provides a crutch for the collective team to lean on so everybody remains on the same page (in terms of timing & expectations). Morning meetings are important so the day doesn’t get away from either party. This is particularly helpful in the final weeks/days of the project.
