#Squad – the Company’s Life Changer

Every organization needs tools to manage projects, gigabytes of data, reports, products, and people. Usually each department has different tools what can generate a mess. To make things more organized and accessible, why not develop an application which could combine the management of all the above? That’s what we did at the Engineering Design Center. We created the #SQUAD application that gathers the Organization/Pod, Rally, SQ, Git data, software engineering metrics all in one place. It has the data that no other tool has, and really makes the organization’s life easier.

How it all started

The initial idea was to have an application which could reflect on our Organization Spotify model characteristics, increasing teams’ visibility to work, and ability to respond to changing priorities across our Digital Technology portfolios. The target customers were: Tribe Leaders, Chapter Leaders, Pod Leaders, Chapter members and Pod members.  

We started with changing the old available prototype and proposal of the Minimum Viable Product 1 (MVP1). We interfered in the interface and its logic. Fortunately, we worked with the PO who was full of passion, had a clear Product Vision Statement and could communicate the main sponsors’ and stakeholders’ needs clearly. With the PO on board, we created new ideas, architecture, design, drive, opportunities, new code and… a new product name - #SQUAD. Later, we managed to convince our sponsors that using the technology we suggested would help to get #SQUAD faster than MVP1, with less issues, bugs and defects rather than the legacy code. What’s more, our team also had the possibility to influence on how the product would be shaped up and what functionalities it will offer to the users. We had a lot of work ahead of us.

The work pace was good with two-week sprints rhythm resulted in releasing SQUAD MVP1 within less than a quarter. In that period, the team not only grew and developed itself in terms of number of team members, but also from technology stack perspective and its maturity. Front/back developers evolved into full stack, and QA became involved more into DevOps activities. The entire team developed architecture capabilities that followed a real cross-functional team model recommended by the Scrum framework and the agile approach with which the team was strongly engaged.

Agile mindset was crucial for the Dev Team

Following the Agile mindset, we also had the opportunities for constructive discussions, feedback sharing and promotion of the Team ’s proposed solutions ideas. It was all about the Dev Team having the ability to decide what technology they want to use, how they want to develop certain functionalities and features, how much and what was taken into each sprint i.e.: new requirements, paying the technical debt and technical improvement. These were not empty, short lived agreements. We really adhered to them as they were essential to allow our development, keep our delivery fast, and not move into regression.

The agility also allowed the Dev Team to have its own Definition of Done, Definition of Ready and Working Agreement that helped with self-organization and with getting less and less dependent on the Scrum Master, who was there only to ask questions and help in auto reflection during Retrospectives.

Having developed the Working Agreement and its maturity, the Dev Team got more ownership and each of the team members could show their leadership skills and become a Sprint Ranger in different sprints.

These slow but steady changes also helped the Dev Team to be better prepared for the Organizational changes where there was no Pod Leader anymore inside the team who could direct the Dev Team and be the functional manager at the same time.

Choosing the optimal technology stack

When choosing the most suitable technology for our product, we took into consideration such things as: team experience, how selected technologies conform to technical and business needs and how rapidly it will allow us to show application live to our customers.

Having all this in mind, we knew that we must be very swift particularly at the beginning to avoid mistakes. Knowing what did not work in MVP1, and observing current market trends, picking microservice architecture was the obvious choice. We integrated independent external REST API with one microservice per one system like: Rally, GitHub and Sonar, which seems to be a more than reasonable choice looking at our business requirements. Structures designed like that are asynchronous systems where scalability is not bound to the slowest one.

It was a no brainer that as a next choice we decided to go with REST architecture style for creating web services. As most of our Developers code was in Java, it was by default that we were going to develop in that language. From that point we were leaning forward to frameworks that were proven and could really speed up development at the beginning.

Considering that our development team had a quite decent experience with the Spring Boot framework, we chose the newest version of it, so it helped us to save time by utilizing past solutions.

During a set of meetings where we were building the technology stack, it turned out that our full stack developer had good experience with code generators like JHipster. We decided to take a closer look at what we could benefit from it and that was the bull's eye. Generator perfectly fit into our fundamental assumptions. JHipster is a multi-awarded generator that contributed to Java ecosystem big time. It is perfect for microservices architecture. JHipster is a development platform to generate, develop and deploy Angular/React Web applications and Spring microservices. Additionally, we had a choice between React and Angular 4, and we went with the latter.

The significant part of generating our application skeleton and basic database model was done via JHipster. After necessary adjustment, we had on the table: fully working microservice architecture with 4 microservices, Eureka service discovery with Spring cloud config, gateway API that proxies all requests to microservices and basic front-end application in Angular 4.

Since we had to rely on some legacy data with the organization structure from previous MVP1 system, we designed a database model for each microservice (one common database for all microservices with one per microservice schema). We supported ourselves with JDL studio - a tool for drawing UML diagrams based on JDL syntax (provided by JHipster.) The tool was easy to work with and produced files with database schema that could be loaded into the JHipster generator. Using those, we could generate most application layers (repositories, services, transfer objects, mappers, resources and basic tests) with basic CRUD as well as Angular components that sufficed enough at that time for initial requirements. For tracking database schema, we utilized Liquibase library operated by JHipster (Flyway was an open option as well.)

Going live - first internal tests

Having the tools in use in a few days, we produced a database model for managing organization data and migrated data from the old MVP1 application. From that point, our stakeholders could manage their data in #SQUAD with limited cases, but at least they began to get used to the new application. We believe that it was a triggering point that made us successful. We were aware that our product had limited capabilities, but the most important was to have the application live, where the product owner and managers could see it. Thanks to that, they could maintain their data in our product and figure out what was working and what wasn’t. That led to broad discussions with our PO in terms of current priorities and future roadmap. From the beginning, our PO didn’t have to wait to see visible results of our work since we could present live demo of #SQUAD at the end of each sprint.

Tuning the app in production

Usually when everything goes well, there is a temptation to underestimate necessary aspects of the development that an end-user does not see. If we blindly proceed, then for sure payback of technical debt blows up in our face sooner rather than later. We have always been honest about what we had to do. At that time, our application worked live on production which we called a temporary environment, hence we had a bunch of work to fully implement the whole CI/CD pipeline. At the same time, we put a lot of effort to build our DEV, QA, PROD environments and automate deployment process with Jenkins pipelines. We built Docker images for our microservices and launched them in Docker containers. Additionally, we configured two dedicated virtual machines, where our team members could manage their own Docker images.(like Postgres, JHipster Registry, Elasticsearch cluster), what allowed to release some system resources. Going further, we configured our CI, so after each push to the remote branch (that created a pull request) tests were launched remotely so the developer didn’t need to wait locally and use local system resources to see the results.

There were a few flaws from using generators that you need to be aware of before using them. Although they dramatically helped to start delivering first requirements quickly, when they became more complex, it was hard to maintain generated code with our hand written one. Therefore, for some time, we decided not to mix it up with the generated one, but since our project became more complex we decided to remove unnecessary parts of generated code merging with the developed one. At current state, generated code was a minor part of our code base. Now we are looking at JHipster as tool that showed us a set of good principles, conventions and patterns that the web application could maintain.

Plans for future

After a period of rapid growth and new critical business requirements development, the time has come to improve our application. In upcoming months, we will focus on refining UX, making users life easier and ensuring that #SQUAD will be the tool of choice for our Organizations.

SQUAD in customers eyes

You may ask how our product is perceived by our customers. #SQUAD is useful in providing a big picture overview of how resources are allocated across product categories/products. It enables management and leaders to quickly see if teams are being allocated to the most strategic/highest priority products.

I use this data to drive many processes from DTS - e.g. SII, capacity planning, resource allocation, resource tracking, quality, velocity, etc. In fact, there are no other tools that track this info in a single pane, and in some scenarios - this data simply wouldn't exist without #SQUAD.

- says Digital Technology Solutions Vice President Chris Carissimi.

Authors:

Joanna Skała-Rutyna, Senior Manager — Software Engineering
Mariusz Gazdowicz, Staff Software Engineer