Experiences of using a Team API?
Opened this issue · 6 comments
Have you adopted a Team API?
What did you change compared to the template?
How did you get buy-in from the teams?
Is the Team API being maintained and does it bring value to your teams?
We are currently in the process of moving towards teams that shall work autonomously on services they own.
Ideally, they will be stream-aligned teams.
I am working on a proposal for a Team API template that all teams can use.
As a first draft, I used the Team-API-template with minor modifications.
I am getting a lot of resistance because someone would have to maintain the tables about team interactions.
The teams would rather do the minimum possible.
Hi @maeh2k - thanks for these questions.
I am getting a lot of resistance because someone would have to maintain the tables about team interactions.
The teams would rather do the minimum possible.
Do the teams understand the reason behind the Team API? Do they understand the value that it can bring to them? Perhaps the team has other unmet needs that need to be addressed before they can really think about team interactions, even if Team API would ultimately help them to be more nimble,
I am in the process of trying to implement for a few teams. Suspect resistance as it forces some definition and boundaries that I suspect some people prefer ambiguous at the moment. However, I will update with progress in the future and let you know how I go.
We have been encouraging teams to create "charters" which include most of the information in the "Team API". SP far haven't seen significant resistance to this idea, and it certainly has been enlightening to see the lack of alignment and common understanding that some existing teams have. We have also found this documentation to be essential when vetting new org designs.
Implemented but called it 'Team Overview' as the 'Team API' was pretty difficult to convey across many teams as a new concept. 'Team Overview' seemed to resonate a lot faster.
Very interesting and useful process. The timeline to implement for 12+ teams was a few weeks. Interesting points below:
- Forced teams to look at how they are structured and operate. Some were alarmed at what they were doing once they saw it on paper.
- Identified inefficiencies in operations. Some teams had too many people which led to investigations why. Brought up issues of development and test processes and down to the lack / absence of unit testing by developers. Also, inefficient implementation of scrum and a whole heap of other issues.
- Identified who was working in what teams and why. This seems basic but it was interesting to see how many teams had ambiguous boundaries.
- Allowed for a greater org restructure.
- Used by external consultants to see structure of dev.
- Many other uses.
Teams are now responsible for keeping their overview up to date. It is now a bedrock of operations. Especially as everyone is remote working.
Just a quick update. The Team API's have been excellent. The Team Leads now take ownership and keep up to date (I keep subtly reminding to update in conversations). Extremely useful as most people working remotely. New people use them to orientate and I use them to see how the teams are organizing and who is in them. I keep them in Confluence. Took a while to get the discipline in place but definitely makes life a bit easier.