Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia. Read Statement
How to manage a company scrum team and a contractor team at the same time?
Currently contractors work on the front end part of the product and the company team on the backend, I just started to implement scrum on the company, for the internal company teams, but I have the question as to if they should merge; the contractors have their pm and standups their not sure if they have their groomings or retros currently they receive requirements and create tickets an work on that, but as both teams (internal and contractor) align to scrum I want to know whats the best approach to this, also if ultimately the company wants to grow their internal team and move away from contractors.
Currently contractors work on the front end part of the product and the company team on the backend
What transparency is there over the dependencies between them, and over how effectively they collaborate to provide a Done increment each Sprint that's immediately usable?
Currently contractors work on the front end part of the product and the company team on the backend, I just started to implement scrum on the company, for the internal company teams, but I have the question as to if they should merge;
Are they considered to be one Scrum Team or two Scrum Teams? How many members across both teams?
If they are two separate Scrum Teams:
- Is there still one and only one Product Owner for the product?
- Do both teams work from the same Product Backlog?
- Do they share a common Definition of Done which incorporates integration?
- Do they have one integrated Product Increment by the end of each Sprint that is considered done?
If the answer is 'no' to any of the above questions, why not?
The Scrum Guide states that “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.”
Does the customer or the final user find much value in building exclusively the backend of an app?
I would try to bring transparency to the organization about the consequences of structuring teams in this way:
- What is the whole whole Cycle Time of a functionality in the full value stream till it gets finally released?
- How much time is lost since the backend team finishes its work and the front end starts it?
- How many times those functionalities have to go “backwards” from the frontend team to the backend team because of communication problems?
I also invite you to investigate about “feature teams” vs “component teams”:
Hope all this info will be of any help in order to move your organization and your teams into action!