Like many other companies, the developers at Bitmovin, have a tendency to split into separate teams when working on different issues and user stories. Internally, for example, the Encoder and the API are developed by two separate teams as different technologies, focuses, and areas of expertise are required to deliver the final products.
Accordingly, both teams are managed independently with multiple Scrum teams.
Although most user stories can be solved independently by one team, cross-team communication is imperative, especially in the situation when we are adding new features to our encoder; which requires additional essential updates to our API that would also allow customer implementation. That means that both teams have to work on specific user stories to ship at the end of a sprint. Over time, we’ve documented that nearly 10-15% of our user stories are dependent on these interconnected teams. Although the individual interfaces are distinct and may be separate in the beginning, there are situations where members of both teams have to work together; for example, during the end-to-end tests of a feature, when some errors occur that did not appear during unit or integration tests.
Most organizations handle these types of user stories or various testing with feature teams (cross-functional teams) [1]; a team consisting of every member required to get a feature done from beginning to end. These teams are typically long-term and will not be restructured between sprints or for every issue. However, these feature teams don’t always work at Bitmovin, as we have specialists that are more familiar with specific technical aspects of our software. As a result, a cross-functional team may fit perfectly for one feature, but may miss a relevant expert for an alternative feature.
Epic Teams
Our goal is to implement a fluid and shifting team that’s capable of completing any developmental challenges that come along with any unique feature. Under the assumption that most feature updates will involve multiple teams working together, the term cross-functional/feature is no longer appropriate, but rather an Epic team [2], that covers multiple, smaller issues across various stages of the integration. These Epic teams will be defined at the beginning of each integration and will work together until the new feature is completed.
During the planning phase of a sprint, the team’s Scrum master is tasked with defining, and managing the Epic teams necessary for the upcoming feature implementation. They are also responsible for documenting and reporting on feature progress. To maintain transparency Scrum Masters are responsible for maintaining the following three methods of communication, that every Epic team must participate in:
- Kickoff Meeting:
The new Epic team converges for the first time to discuss the design and implementation steps that will be necessary to finish a new feature. The Epic team will also discuss any other previously unidentified needs or requirements of the project, and how to handle them. - Daily Standup:
Aside from the regular team stand-ups, the collaborative Epic team will do an additional, custom standup. The same rules apply as for the regular standup. - Shared Slack Guidelines:
- Create Unique “Epic” Channel: No private messaging – information may get lost
- Communication about Epic projects must remain within this channel. This also assures that Team Leads, Scrum Masters, and Product Owners are up to date. If a new member joins, the full history can be read by the newcomer.
- Channel Naming Convention: #gh-issue-number-short-description (e.g. #gh-1234-awsome-feature)
The Scrum Masters of individual teams (ex: Encoding team & API team) ensure that members maintain a high level of focus based on highest priority objectives. In addition, Scrum Masters are tasked with managing the tasks of members so that no individual project deliverable impedes the progress of another team member.
The use of Epic teams allows Bitmovin to utilize the best experts for each unique project and integration while maintaining an agile workforce.
Future Development
We see this as an interim stage for Feature Teams. As these Epic teams work together and grow, their knowledge will spread across multiple developers and increase the capability of all of our teams! We may switch back to feature teams at one point in the future when longer term solutions are required, but for the meanwhile; having a temporary highly flexible and agile team is the ideal working scenario for Bitmovin.
For more readings from Bitmovin, check out the following links:
- Trends in Online Video for 2019
- 11 Things Your HTML5 Web Player Must Have!
- What is DRM and How does it Work?
[1] https://less.works/less/structure/feature-teams.html
[2] http://scrummethodology.com/scrum-epics/
