By Rodrigo López, CIO at Toolbox

The main role of the Technology Department at Toolbox is the execution of developments that evolve the world of online TV as quickly and efficiently as possible. We focus on the issues related to the OTT world, providing solutions with high-end technology.

To clarify: OTT (Over The Top) refers to those content services that are mounted over the operators’ communication networks. The solutions we offer today at Toolbox include
OTT Solution, for the direct distribution to the user through the internet, Cloud Pass, with user authentication services, and Unity, for content distribution and aggregation with a single integration, to mention some of our productions.

The fulfillment of this mission is a challenge that demands an internal structure, a dynamics of operation of the teams and a work style of the members of those teams.

Internal structure

Generally, the products are in the hands of two departments: the Product department, and the Technology department, which is the one that concerns us.

Technology is divided into several teams that could be grouped into two units: Development, and Implementations and Support While the Implementations and Support unit is formed by one single team (see below), Development has four:

  • The Architecture team defines how the system will be assembled, how to achieve scalability, makes sure that the general development guidelines are followed, makes sure that the rules of the Revision Code are met, establishes the governance processes and the systems for monitoring the application, proposes improvements for the optimization of execution, etc. It has countless responsibilities and is a very proactive team: it is constantly monitoring applications and proposing improvements.
  • The second team within the Development unit is referred to as Player because it is in charge of this product.
  • The third is the Edit team, which has been historically associated with our Unity product, but it currently deals with other products, such as Profile Management.
  • The fourth team within Development is the one called Experience. Like the other three, it handles multiple products.

In general, each team has several developers, one technical-functional analyst and one in charge of quality control (QA), and each team is led by a Project Manager.

At the same time, the Implementations and Support unit performs tasks that can be summarized in three areas:

  • To assist clients in the use of Toolbox products and to solve any issue that may result from their use.
  • To execute the integrations of both the Content Providers (CP) and Identity Providers (IDP) into our systems. That is, the team is responsible for integrating new Toolbox clients, and other CPs or IDPs that require integration with our platforms by our customers.
  • Follow up with the implementations of the Toolbox systems into third parties’ systems.

Dynamics of operation

If we take a look at the four development teams, we will see that they work with two different methodologies. While Architecture and Player work with a KANBAN methodology, Edit and Experience work with a SCRUM methodology. This difference is due to the fact that we consider that the stages of the products and the requirements that are important for each team, are different. In our case, KANBAN is more useful than SCRUM in the earlier stages of the products, as is the case with Architecture and Player.

The teams that work with KANBAN have their own backlogs, which are weekly prioritized. Every week they identify their WIP (their capacity to Work in Progress, the amount of work they can do in a week) as well as the projects they have to execute. While new tasks are added and, based on the WIP and the projects, each week the backlogs are re-evaluated, in order to change priorities where necessary, reconsider execution times, or atomize tasks.

With SCRUM, the methodology with which Edit and Experience work, the work is done based on sprints (iterations that must be given in a certain period of time), during which the pending tasks must be executed, ensuring a (measurable) verifiable delivery of value. Every morning, around 10.00, daily meetings (update meetings of approximately 10 minutes) are held, which include the team members working in the office and those who work remotely (for this is we use video communications).

On Fridays, we hold a planning meeting where tasks are assigned, and delivery times are estimated. These estimates are made through the poker planning system. It is a game system that uses decks numbered with the Fibonacci sequence, which enables a focused discussion about times and efforts that a task involves, including those responsible for the development and those who have expertise in the subject. To close the SCRUM cycle, retro meetings are held every fifteen days, in order to analyze what went well and wrong, what was appreciated and what was not, what is new and how we should continue. This helps refine the methodology to work better every time.

Work style

Whoever comes to our office will see how we work, although something might catch their attention. At a Friday meeting, if you see someone who’s speaking wearing the Harry Potter hat or holding the C-3PO action figure, it’s because that token helps the conversation stay organized and appropriate. If you see printed “memes” (like those going around WhatsApp groups, Twitter or Facebook) with quotes such as “If you don’t give time for the QA to test, the QA won’t be able to test”, it’s because we immortalize our retro meeting conclusions that way. Challenges come with work but staying relaxed is the best way to face them.