The Central Services Problem

In large enterprises, a customer-facing product development team often has dependencies on other teams for frameworks, underlying systems, and (very often) centralized platform APIs. The most common scenario in large enterprises is a central Platform Services team that provides APIs to product teams for access to underlying data and service workflows.

The point of this post is not to critique that model, but instead to accept this model exists and work with it as best we can. These central Platform Service APIs are a product in themselves, with customer-facing product teams as customers.?

Delivering a full slice of functionality of a given feature is the only true example of delivering value, but this can be challenging when team dependencies like this exist, which they often when dealing with scale. This central services model can produce frustrated customer-facing application development teams because they may be waiting on a Platform Services API team to provide those services or endpoints they depend on. So, what does the product team do? They can:

1. Mock out the Platform Services API based on proposed contract (which may change)
2. Put in an abstraction layer over the Platform APIs that would be unnecessary should the services be directly available, because it’s easier to mock and doesn’t predict service contracts. Then mock that, adding a layer of premature abstraction to your design.
3. Send the Product Owner over to fight for positioning in the Platform Service team’s backlog. (This should probably happen anyway, but let’s assume that fails because the product team needs aren’t at the top of the list).
4. Submit a Pull Request to the Platform Service team?s repository to provide the service capabilities the product team needs.

Ding, ding, ding. That last one is the right answer. The product-facing team submits a PR to the Platform Services?API?repository. What a great solution!?The ultimate prescription for success here is to use an internal open-source workflow model and submit code to the Platform Services team to accept into their codebase.

Then the PR is rejected for a myriad of reasons that boil down to the PR-issuing team not understanding the conventions and policies of developing code for the Platform Services team APIs.

A Team Safari

Consider a Team Safari (we call these Agile Safaris at GoDaddy).

A Team Safari is when one or more members of a team leave their home team to join with another team for a Sprint or two to solve a problem and learn more about that team’s software systems.

Why would a we do this? After all, it decreases the capacity of the team left behind for the time the team-member is away. Further, the receiving team capacity is eaten up teaching the new developer how everything works.

The short answer is everyone benefits from high-quality PR being accepted. If the product-facing team can issue PRs that get accepted to the Platform Services?team, everyone benefits. The Platform Services team grows its API services footprint. The customer-facing team gets the service it needs.

A Successful Safari Recipe

When a Team Safari is used, there are some ground rules to help things go much better than for a developer to just move a desk over and announce, “Here I am! Safari me!” In addition to core platform capabilities, the visiting engineer will greatly benefit from gaining a working knowledge of all aspect of the visited team practices, patterns, underlying architectures, etc.

First and foremost, ensure the Engineer on Safari is there to solve a specific problem, or learn a specific skill. This should be summarized in a clear and concise ?purpose statement? everyone involved understands.

If the following are approached methodically, once the engineer returns to the home team, he or she will later be able to issue successful PRs to the team visited. The following knowledge will help ensure those PRs are accepted the first time.

1. Standards, conventions, and architectural guidelines of the Platform Services APIs public interfaces.
2. Standards, conventions, and architectural guidelines of underlying systems capabilities including data access, logging, security, etc.
3. The underlying language (probably a prerequisite to the Team Safari anyway), documentation, and coding standards.
4. Full understanding of the CICD team?s CICD pipeline, to ensure appropriate unit and integration tests are included with the PR and pass appropriately.
5. The specific test-first or other developer testing practices used by the visited team.
6. The greater architecture (if applicable) of the visited system, framework, or technology if appropriate. Not just solving for the stated purpose, but doing so in the visited team?s context.
7. Any teams and system the Platform Services team depends on, and how those dependencies relate to each other.?

Paying Back on the Investment

Not only does the Team Safari inform the developer who went on Safari, but that knowledge eventually gets transferred back into the home, or product-facing team then the developer returns.

And now, we don?t have to wait for the Platform Service team to work our Product Backlogs to the top of the queue. The newly informed team has someone who can create real PRs that are accepted and deliver on the promise of working software each Sprint.

As stated, the visited team now has the added capability the accepted PRs provide. Everybody wins.

Do you and your teams use Team Safaris or something like them? Let e know in the comments.