Since the beginning of the times, development and operations teams are too far away from each other. I’ve seen many problems happening because of that. This post will tell a bit about these problems and how we can engage both teams.
Before we all talk about microservices and DevOps, development and operations team have always been far away from each other. It means that both were two separated teams with different goals.
Developers were more focused on coding business features and deliver them. Operations team had a focus to keep environment up and running, security, tickets up to date.
But what if the system is down in production? The teams start blaming each other. One will say “database is really slow”, other will say ”your system doesn’t work and your modeling doesn’t look good”. I’ve seen this kind of thing many and many times. It’s easier to blame the other team than getting together and find a solution.
Now we started talking about “getting together”. How cool is that? What if both teams worked together and had the same goals? Instead of just coding or just closing tickets, both teams could work together, discuss solutions, help each other, automate things with one goal - deliver a better software/environment and consequently, more value to the business.
It seems weird that in 2017 we still have this kind of problems. I’m a developer and I’ve seen this kind of conflicts in the past and it still happens.
But what can we do to get together development and operations teams?
- First thing is to change the corporation’s mindset, both must be engaged and aware of the business goals and for that higher management must buy it.
- Stop communicating through tickets, please! Come to each other’s desk and talk face to face.
- Operations team could (and should) participate on daily meetings (and other meetings) and not be contacted just when the sh*t happens. This way there will be a better communication and better relationship with developers and business.
- Why can’t ops and devs pair program? If the idea is to engage both teams, the pair programming is a very cool idea. There’s always something that can be automated and improvements to do.
- Think about one team with different skills, not two separated teams with different goals at the end of the day.
There is a lot of things that we can do to engage both teams and deliver better software. Mainly with the microservices/lambda’s era, where everything must be automated and highly available.