What is SDMX?
SDMX, which stands for Statistical Data and Metadata eXchange is an international initiative that aims at standardizing and modernizing (“industrializing”) the mechanisms and processes for the exchange of statistical data and metadata among international organizations and their member countries.
SDMX INTRASOFT international team supports the implementation of the following tools:
- The SDMX Converter is a Java application that converts statistical datasets between different formats. Its purpose, to convert files between different formats, is complementary to that of the SDMX-RI, which can generate SDMX-ML data directly from databases.
- The SDMX-Reference Infrastructure (SDMX-RI) is a set of pick-and-choose building blocks and tools that allow data to be exposed to the external world through access rights by using web services. Thus, it creates a universal framework for modern data provision – single exit point – an interlocutor to Eurostat’s Single Entry Point.
SDMX’s team structure
Currently, the SDMX team consists of:
- 1 proxy PO (Product Owner)
- 1 ScM (Scrum Master)
- 8 software engineers
- 1 manual tester
- 1 automation tester
- 1 UI/UX expert.
Waterfall Model vs. Agile Transformation
Initially in SDMX a waterfall model with linear sequential phases was adopted with no iterations. As a result, it was very difficult to absorb any changes to customer requirements and to monitor our progress towards customer’s satisfaction.
Furthermore, due to the lack of iterations the team struggled to have a better understanding of what or when to deliver the implemented items. Endless meetings were scheduled to present and to give rough estimations of all items that the team would get involved in the upcoming quarter. Thus, the team didn’t have enough time to make a thorough investigation of every item and consequently the probability of bad estimations was substantially high.
Before my engagement with the SDMX team, it was already decided to explore the Agile approach. Luckily, due to my experience as a ScM it seemed that the Agile transformation would be smoother and now was the right time to start this journey.
Agile transformation journey
To begin with, it is very difficult to convince people that used to work and collaborate in a certain way (even if this framework is already evident that it isn’t efficient) to change and to adopt a new one, more “agile”, if those people don’t have the right mentality. Whenever existing processes and methods are challenged by new ones which propose a better way of doing things, it is generally observed that people working in the particular organization become apprehensive and feel uncertain about what changes the new system will include.
The SDMX team had the required “agile mindset” to overcome any obstacles or impediments identified during this transformation. Top level management became an ally and provided the team with all the relevant resources to accomplice our goal. The first step was to identify where we are regarding agility across a wide range of roles, workflow processes, product performance, understanding of our customer, and much more, “Why does the team needs to transform to be more Agile?”.
Afterwards, key concepts (roles, ceremonies etc.) of agility were presented in order for every team member to have a first touch with our new way of working. Scrum was deemed to be the most appropriate agile framework to fit our needs. Furthermore, a roadmap was created to have a clear view of our progress during our efforts.
Agile Ceremonies
The SDMX team has adopted the following ceremonies:
- Daily stand up
- Sprint planning meeting
- Sprint review meeting
- Retrospective meeting
As agility instructs “all agile events to be kept within the timebox”, that was our initial challenge. Cutting out the distractions and drilling down to the important topics and tasks was the first step to succeed in time punctuality.
Another key aspect of the agile transformation was the understating and importance of Retrospective meetings. The purpose of agile retrospectives is to reflect, learn, and decide upon improvements that teams will do. If people start blaming, then a negative culture is cultivated which blocks searching for solutions. It hampers the team spirit and the relationships between team members. So, without having a coarse understanding of the benefit and scope of retrospectives, it is very common to facilitate a meeting were someone is blaming, and others need to apologize. In SDMX due to our mentality and openness we didn’t face these problems and our retrospective meetings were and still are an invaluable tool for improving team dynamics, processes, and productivity.
Definition of Done
The DoD (Definition of Done) is usually a short document in the form of a checklist, that defines when a product backlog item (i.e. user story) is considered “done”. Prior to SDMX’s agile transformation there was no criteria to decide if an item could be considered as “done”. It was up to every engineer to decide if an issue was done or not, which led to not having a common alignment.
After the agile transformation of the SDMX team, a DoD and DoR (Definition of Ready) were created which helped us to ensure transparency and quality fit for the purpose of the product and organization.
UI/UX expert
The SDMX team also features a dedicated UI/UX expert responsible for the look and feel of SDMX’s user interface. Before the agile transformation UI/UX experience was an undiscovered field that none of us had ever tried to experiment. Since the new Agile era in SDMX, team and management level decided to invest in UI/UX disciplines.
For this reason, a dedicated UI/UX engineer joined forces to meet customer’s expectations for an excellent look and feel of the application’s user interface.
Conclusion
Agile transformations enable teams to become highly responsive, do more with less, and better serve and support customer needs. To succeed, an agile transformation requires significant support and resources from top management. The SDMX team showed commitment and professionalism during this journey and with the guidance of the Enterprise’s Agile Coach we succeeded to minimize time and resources waste.
Author: Konstantinos Tsekos.