Changing to an Agile mindset
My experience moving from traditional IT to an agile mode
“There is a bewildering limitation of our mind: our overconfidence in what we believe we know, and our apparent inability to admit the true extent of our ignorance and the uncertainty of the world in which we live.”
Daniel Kahneman
Introduction
One of the oldest and most tender memories I have as a child is lying on the carpet in my parents’ living room playing with Lego, eating sandwiches, and reading books like the Disney encyclopedia, an old world map atlas and a bunch of National Geographic magazines from the 80’s. Through those pages, I was transported to different places with different cultures, languages, and people. Thanks to the power of reading, I broadened my horizons, one page at a time.
Just like my youngster me wanted to expand his world, I felt that this was the next logical step in terms of career for me. I planned and researched a lot, including an in-loco job hunt in Portugal in 2017, but it was only in 2019 that I was lucky enough to find a good opportunity in a company that was starting just now and was willing to face old challenges with a brand-new approach. This company is, of course, tb.lx.
Interestingly, I also felt that I needed to face the professional challenges that I would encounter in this new endeavor using new approaches. And once again, I was lucky enough to find a multidisciplinary and multicultural team that made me review and reassess work processes and methodologies that I found, in the absence of better words, proven and universal.
Then and now
Just over ten months ago, I was a typical system administrator on an IT operations team, working for a large global outsourcing company — and there is no demerit to my claim, believe me: I loved my job, my employer, the customer where I used to work on-site and the technologies I used in my day-to-day life!
A typical day started with a quick check on the records of the changes that had been planned to be carried out during the night shift (if everything had gone A-OK, if any changes in the environment had been reversed, if both the primary and secondary sites were operational, among other things). This type of verification was necessary because although we operate two data centers, there was little room for maneuver if any aspect of our infrastructure crashed; redundancy was limited to a few systems and increased our delivery capacity was always costly, technically and financially speaking.
Cloud and Infrastructure-as-code are your best friends
At tb.lx, on the other hand, our entire infrastructure is cloud-based, which means that our geographical reach, our flexibility to respond to incidents, and our agility to resize the data transfer capacity is much higher than traditional, on premises-based infrastructure. Our systems are, by definition, prepared to be scaled both horizontally and vertically if necessary. Due to the economies of scale provided by our PaaS (Platform as a Service) supplier, the costs and complexity of adding additional infrastructure are much lower than the traditional IT models based on incremental purchases of hardware and software licenses.
Regarding our infrastructure, it is completely code based. There is no database, container, or virtual machine that is not expressed through lines of code. All implementations of new features in our environment go through the same review and quality process to which the solutions we develop for our customers are submitted. It includes versioning the source code, revising the proposed changes, automatic validations, and automated deployments. A “side effect” of this approach is that both developers and Site Reliability Engineers (which are a new approach to operations) ended up speaking the same language, which reduces friction and makes it easier to understand the challenge to be overcome.
Automation for the win
Going back to my not-so-distant past, I used to have a queue of tickets and incidents to call my own. There was a little bit of everything: there were disks to be created, file systems to be formatted, network configurations to be applied, deployments of new servers (physical and virtual ones), and security updates. Most notable, however, was the amount of repetitive work I used to do every day. These were valid and important activities, of course, but I did not deliver any real and immediate value to my customer. And when someone on my team commented that this or that activity could be automated, we were always reminded that we shouldn’t add complexities to the environment. Our mission was to keep the infrastructure running without any hiccups, 24 hours a day, 365 days a year.
At tb.lx, we also have all kinds of activities, and they need to be performed the same way as in any IT company. The big difference, in my opinion, is the qualification of the type of work. For example, if a task can be done programmatically, then it will be modeled and automated. It ensures that our solutions are performed automatically and evenly, minimizing our failure rate and releasing our professionals to dedicate their time to challenges that deliver immediate value to our stakeholders. An emblematic case in this type of approach is the extensive use we make of pipelines, which are nothing more than a method to deliver applications frequently to customers. Thanks to this, we were able to solve the problems that the integration of new codes can cause for the operations and development teams in a much more proactive way.
Agile teams have no “us vs. them” mentality
In my old life, with a certain frequency, the developers used to call to inform my team that the application “ABC” was not working properly. Phrases like “accessing the database is taking too long,” “CPU consumption is too high,” or “the error message XYZ is being displayed on the logs” were sentences that we always heard. No context was shared between us: after all, in this Game of Codes, you either win or die. They accused us of having changed something in the infrastructure; we accused them of breaking the application in the last update. At stake, the honor and dignity of the teams. Only one could be victorious, but in the end, everyone loses.
On the other hand, we at tb.lx understand the value of working as a team. This kind of “us against them” mentality has no place in our culture! If a problem occurs in one of our products, for example, it is a problem to be solved by the entire company, and all professionals are available to help.
Another pillar of our culture and our work method is the concept of shift left, in which operations concerns move earlier in the software delivery life cycle, toward development. The goal is to allow development teams to develop and test against systems that behave like the production system so that they can see how the application behaves and performs well before it’s ready for deployment.
Conclusion
This new phase of my professional life has been one of the richest so far. I’m privileged to work with new technologies, new collaboration models, and new work methodologies that are more efficient and flexible, and that also enables the entire tb.lx to focus on activities that deliver real value to our customers. It’s equally wonderful to work in a place where all professionals collaborating on a given project are using a lingua franca that minimizes friction and communication problems. In retrospect, my horizons have never been more expanded than they are now.
Feel free to contact me if you want to explore further this and other subjects related to DevOps, technology, and agile methods.
Daniel Meireles is Brazilian and works as an SRE at tb.lx in Lisbon, Portugal.
