Stratio is a technology company that was born in 2013 with the aim of creating a product that solves the main challenges faced by a company when implementing a Big Data solution. Stratio is firmly committed to agile frameworks and, right from the start, its hallmark has been the self-organization and multi-disciplinarity of the teams that the Scrum methodology proposes.
At the time of writing this post, Stratio has experimented a virtually exponential growth, having gone from 20 employees to almost 300. This growth has been a challenge when considering the way of working and the interactions between the different professionals that make up the company.
Initially there were few teams, all of them executing Scrum, and the way to handle the interdependencies did not seem to be a challenge. When the company started to grow, a Scrum of Scrums meeting was the choice implemented, and for a period of time, this meeting was enough to synchronize the interdependencies that existed between the different teams. With the passing of time and the growth of the company, which implied a growth in the number of teams, this meeting ceased to be effective. The large number of interdependencies and the lack of predictability in how these were resolved made it impossible for them to be managed just by the Scrum Master. To try to alleviate this problem, the technical representatives of each team were invited to the meeting and even though this improved the situation, it was simply not enough to synchronize all the teams or manage the interdependencies.
Adapting Scrum to our necessities
We were then at a point where we had the need to scale Scrum from other points of view. The initial proposal was to implement Nexus in the company. This framework of scaling involved several organizational changes such as the need to eliminate the different Product Backlogs of the teams in order to generate a unique Product Backlog for all. New roles were also generated, such as the NIT (Nexus Integration Team) in charge of ensuring the integration of the product and new events such as the Nexus daily scrum, where all the teams meet daily to deal with their interdependencies. Despite the changes introduced, this framework did not achieve the desired goals. This was due, among other things, to the peculiarity of Stratio’s product, which we can define as a suite of products. This translates into a product that has shared goals but which also generates independent evolutions of each of its modules, that is, several Product Backlogs integrated to build what is now Stratio.
Although we studied other frameworks such as SAFe and LeSS, the solutions we knew so far were not enough to cover the scale model that Stratio needed to build its suite of products.
Creating our own Agile Framework: Argos
Due to all of the above, we finally decided to embark on the creation of our own framework. This is how Argos was born, a framework created to develop independent products which are integrated into a single final product. It is a framework that, among other things, brings together best practices from other frameworks such as SAFe and Nexus, in addition to making use of Scrum and Lean Kanban, and which in turn works with different Product Backlogs, giving great importance to the management of interdependencies and a very deep refinement that helps define a transparent and aligned Roadmap which can generate the greatest possible value for the suite of products.
Our framework starts with a meeting called MetaScrum, this meeting was proposed by Serge Beaumont and Jeff Sutherland in 2006. MetaScrum has a purely business focus, it brings together management profiles, stakeholders and our Chief Product Owner to align the objectives of Stratio’s business.
These objectives are transferred to the rest of Product Owners by our Chief Product Owner to transform them into team goals. In this way, each team knows how they can collaborate and carry out the business objectives defined by Stratio.
From here onwards starts a phase of high importance for the team that manages interdependencies. The Stratio Product Suite entails a great complexity when trying to manage a single product which in turn is made up of different products, that is why the management of interdependencies is key for the correct simultaneous working of the team in each of the iterations. To address this problem we have a series of meetings focused on dealing with the teams’ interdependencies in the ongoing iterations, as well as to predict the interdependencies that we will find in the following sprints. In addition to easing the resolution of inter-team dependency problems, we have created a team in charge of its coordination, the Product Integration Team.
With the clear team goals and the detected interdependencies, we started our Sprints in a coordinated way, in which we have dailys where we review the interdependency plans that have been previously detected.
Another important aspect in our framework: Refinements
Another aspect of great importance in this system are the refinements. Refining gives us two crucial aspects, forecasting and early management of interdependencies. By refining and knowing beforehand the work to be done in successive Sprints, we can give an approximation of when the functionalities described in our backlogs will be launched, which brings great value to our customers. In addition to this, this work allows us to make an early detection of interdependencies and facilitates their subsequent management. The fact that a team knows in advance if it will have an artefact from another team during the execution of the Sprint or if, on the contrary, it will not be available, and therefore the task cannot be completed, it simplifies the planning of the different teams.
Finally, we reach the most important event in our system of continuous improvement, the Retrospectives. In addition to the classic Retrospective of the development teams, we have one at product level that helps us to improve the common processes related to deliveries, management of interdependencies and synergy between different modules, and another one oriented to Product Owners where they can improve the aspects related to the definition.
Argos allows us to scale not only at the development level but also at the level of definition by having a Product Owner for each module that follows the directions of the Chief Product Owner as defined by the company. It also allows us to scale in an orderly manner in which each team can follow their own Agile method, either Scrum, Kanban or even scaling frameworks that have a single Product Owner such as Nexus.