The optimal IT development team 9 - DevOps

I also touched on the agile principles and Scrum and how to get started with using them in practice. Then, I talked a bit about communication, collaboration, and the importance of getting to know each other. After that, I delved into how you can implement the CI/CD mindset in your team and how it can contribute to keeping the team's deliveries always up-to-date.

Then, I published an article that focused on conflict management and stressful situations, what can be done to prepare for them, and how to handle them in different ways. After that, I wrote a bit about how you can inventory areas of responsibility and competencies in a simple yet effective way. And finally, I wrote a bit about how you can assess knowledge levels within different competency areas.

Now, it is time for the last article in the series, where I will describe how you can implement DevOps in the team, which is a way to tie everything together in this series.

As I have emphasized throughout this article series, one of the most crucial building blocks is to create a work environment where everyone feels they can express themselves without being ridiculed or neglected and where there is an open atmosphere for giving and receiving feedback. If you can achieve this in your team, you have come a long way. So my advice to you, as you read this article, is to open your mind and try out my simple tips and methods, even if they may feel a bit unfamiliar at times. Take the time to revisit the articles that focus on teamwork and how to foster trust among team members.

An important aspect of DevOps is automating repetitive tasks that are not well-suited for humans but rather for machines. This is not a new concept at all. Strategic work in the spirit of automation flourished in the latter half of the 18th century during the Industrial Revolution, where the automation of the textile industry with the "Spinning Jenny" served as the first clear and concrete example.

I have previously discussed how you can automate a significant portion of the work in an IT development team in relation to CI/CD processes. However, I believe it is essential to highlight the importance of this work, as it is a fundamental building block in the implementation of DevOps.

Two important aspects when implementing DevOps are the ability to manage versions of different elements such as documents, configurations, source code, firewall rules, and more. To succeed in this, you can utilize the convenient tools that are available and that I have described in previous articles. The advantage of checking in and out documents is that it simulates a simplified database engine where you can constantly have control over checked-in versions, who made the changes, and easily roll back if necessary. In the database world, this is nothing new; transaction logs have been around for a long time. However, it is still a relatively new concept in the infrastructure domain.

Traditionally, infrastructure has consisted of physical elements such as hubs, switches, routers, servers, storage networks, firewalls, load balancers, and so on. But with today's technologies, it is possible to virtualize a significant portion of the infrastructure, allowing you to focus on the services offered and the business value they provide rather than hardware considerations.

Tools that abstract infrastructure and transform it from hardware to code are already available today and are highly recommended if you want to move away from hardware dependency.

I have previously mentioned products like Kubernetes and OpenShift and how they can facilitate your work as a team leader or product owner. Suddenly, you can avoid worrying about how hardware should be dimensioned and instead focus on the services to be offered and the requirements they need to meet.

One crucial aspect to consider is that many individuals come from a more traditional background in the IT industry. Given that, it becomes essential to explain why DevOps should be adopted in the team and what we could gain from it. There is a danger in allowing developers to take over more and more from system administrators and teaching them how to configure systems, create development environments, manage permissions, etc. The danger lies in developers getting overwhelmed with administrative tasks when they should be allocating resources to developing the product. I have seen several examples where developers are overutilized as system administrators when they should focus on what they do best: writing code.

With that said, I want to draw your attention to the danger of pushing DevOps too far and it becoming overly focused on Ops...

Traditional system administrators will always be needed for the underlying hardware where everything is running. Even if you place all your applications in public cloud services, there are still people responsible for managing that hardware, even if you don't have those resources in your own team.

Another way to abstract and virtualize the hardware layer is to leverage cloud services in various forms. For example, you can choose to migrate all of the company's applications to a public cloud service like AWS, GCP, or Azure. However, there are also other options, such as running a private cloud where everything remains within the company or a hybrid variant where some elements are located in your infrastructure and others in a public cloud service.

Regardless of what you choose to do, this is also an important component in the DevOps mindset and facilitates collaboration between "DEVelopment" and "OPerations." Traditionally, development environments and system administration have been somewhat separate worlds, with each side often blaming the other whenever something goes wrong. DevOps is a way for these areas to come together and gain a better understanding of the requirements, needs, and desires within each respective area. With a cloud service, it also becomes easier to treat many more things as code, which can be checked in and versioned in various ways.

This article concludes my series on setting up the optimal IT development team, and I sincerely hope that it has provided you with valuable tips, advice, and insights into what is important to consider when assembling a team and trying to make the most of it. I also have some ideas for future article series, but I'm open to suggestions, ideas, and requests regarding topics that might be interesting.

Feel free to send a message via our contact form, and I promise to respond as soon as possible.