Structuring an Internal API Team in an Agile Environment

Question

My company has adopted scrum two years ago, and I think we have been fairly successful using it. I am currently facing the task of trying to restructure part of our development organization, and I wanted to get some input.

We currently have 3 product teams which are developing web-based, client facing applications. We also have an API team that develops an internal API which the other teams are using. In the coming 2-3 months, the API team's backlog is going to become ever shorter since the team has delivered most of the features required by the product teams. Product teams work is going to continue beyond that point.

Someone will need to continue and support the internal API. This work would include:

1. Bug fixes
2. Performance enhancements
3. New features (only a few are expected)

We are considering a few options of how to restructure the teams to better support this:

1. Reduce the size of the API team to match backlog size and needed velocity, and have it continue to support the API as it did before.
2. Disband the API team, and embed it's members in the product teams. The API would become a shared resource and all teams would add features and fix bugs as they see fit.
3. Leave only a core API team, and embed the other members in the product teams. Product teams would add new features and fix some bugs they care about. Core API team members would implement platform features like performance, instrumentation, etc. They would also do code reviews for product teams, and shepherd any changes made to the API.

I would love to hear any other suggestions we might be missing, and also get some insight based on experience anyone might have had using any of the methods above (good or bad). My goal is to create a structure that reduces cross-team dependencies (and blocks), while still providing some supervision for the API.

Any links to additional reading I should do on this subject is also greatly appreciated.

Thank you

Answer 1

I wouldn't change the API team at all. Once you have a group of people that have become effective at working together, it's generally best to leave them together.

Instead, consider starting to slowly add non-API work into their backlog, starting with a low mix and steadily increasing until they become a fully-functioning product team that also are the API experts. This allows that capability to remain fully-assembled while also using the team in other capacities. You may find it helpful for cross-training if a somebody wants to "trade spots" from the API team to a product team, but this should be optional and truly a volunteer behavior on both sides.

Answer 2

I would probably go for solution 3, the reason for this is that you need to establish a clear and defined ownership of the product. This will ensure that needed work will be done (as pointed out by Trevor) and minimising unnecessary conflict scenarios.

The second proposed solution might work, however it depends strongly on the teams involved, their motivation and workload.

One aspect worth considering when restructuring your development groups is how it will affect your team members from a psychological point of view. Reducing a team that is used to being a backbone to the other teams might lead to a decrease in motivation. The people left behind in the core group might see it as if you think that they are not as productive or as good as their co-workers that got to work on the new product teams.

I would recommend reading in to the FIRO group dynamics model and how a change will affect your team members.

Answer 3

While admittedly this isn't my realm of expertise, it sounds like you've almost made the decision as options 1 and 3 are basically the same. From an outside perspective, since there are 3 independent teams that rely on the API, it seems like the best route is to leave a dedicated team to work on that. This insures that when any changes are made, the other two teams requirements and concerns are accounted for as well.

Answer 4

You absolutely should keep this team together -- they've likely been together for some time now and have an established velocity. Distributing them out to the other teams is certain to disrupt the existing velocity and possibly set those teams back into forming-mode. If the API work is drying up, consider other feature work to flow into their backlog, in addition to the API maintenance, but I would advise keeping them together, if at all possible.

Beyond that, it behooves more and more product organizations to truly understand the value of their API. Treat your API as a product and ensure that all efforts to market it as such are investigated.

When considering organizational changes in a software organization, always consider Conway's Law: http://swreflections.blogspot.com/2012/10/should-you-care-about-conways-law.html

Be cognizant of the potential affects to your API, over time, if you disband those individuals and essential change their focus. They are now incentivized to ensure that their features work, but quite possibly lose sight on the value of the standards and discipline they built together, over time, as a team, working on the API with ownership and pride.