How did we benefit from Contract-First REST API Design Approach?

To recall, the fundamental purpose of this blog is to share openly the best practices we had as the Scrum team from a Product Owner Perspective. That’s why it makes sense to share a typical approach we follow while developing new features by cooperating with client development teams with a strict deadline or  time pressure. It’s Contract-First REST API Design. A recent example of this was a back-end development of a new Payment channel to sell recurring TV packages to end users through the TV Web portal.

To launch this commercially, the in-house Web portal development team was relying on us to progress further and actively developing the brand-new web pages. Besides, the launch date was fixed and committed to the top-management.

Even though the deadline was approaching, since the earlier Sprint has failed, as the PO, I had to prioritize the relatively small work that was left over at the Sprint Planning event. My perspective was as the whole team had focused to ship the Sprint goal of the previous Sprint and we are pretty close to bring it to Done state, I set a Sprint Goal that dictates to continue to work on the earlier goal and only to take small baby steps regarding the payment solution. My rationale was freezing the work we already had started and progressed a lot and focusing on something totally new wouldn’t be an effective way of utilizing team’s efforts.

While we had just started a new Sprint, I’ve faced pressure from various parties such as my own line management, my business contact and also project management office who governs the overall payment solution. They pushed me to change the direction of the team so that we focus primarily on the Payment system solution.  At first, I resisted to make a change on the original Sprint Goal. ( ‚Not-changing the Sprint Goal unless an extraordinary thing happens‘ is also one of my commitments to the Development team) After a series of discussions we’ve come to a point where it sounds feasible that we stretch team’s capacity and deliver Contracts to the client team by adapting a Contract-First API approach in order to unblock the Web portal team’s development in the current Sprint. This would mean around %10 extra workload to the team. At the end of the day, now I think it was worth to it.

reference: 

By delivering the Contracts for a total of 12 services for 3 different 3rd party components we had 3 significant benefits:

  • Flexibility: Focusing on delivering the contracts first rather than starting with the implementation, allowed us to make minor changes on the input/output parameters of the APIs later on if necessary. Additionally, client teams was able to provide very fast feedback while progressing further.
  • Time-to-Market: By shipping the contracts to the Web development team (client) released them to go further regarding the development . Preparing the contracts first let us to run the work of two separate teams in parallel without depending on each other.
  • Team Collaboration: One developer from our team (back-end) and one developer from Web portal team (front-end) collaboratively worked together on the design of the API, what should be request and response in detail including the business logic. Hence, both teams are committed to hit the deadline and to ship the solution on time.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .