Putting DevOps into perspective. Back in the day, I was once the sysadmin assigned to a software development project team working on a new enterprise resource planning application implementation. My job was to support the development team for any of its sysadmin needs – such as installing software, expanding a filesystem, or applying a patch – if it was a sysadmin need on that project, I was the guy. Our job was to deliver this new application on time and within budget.
Not that everything was copacetic all of the time. As was the practice of the company I was with, people working on special projects were physically relocated to another building or work area so that everyone on the team could sit together. However, in this case, everyone was relocated except for me, as agreed between my manager and the manager of the software development team. As a result, I would spend parts of my workday with the rest of the project team and the other parts at my usual work area. While I was able to take care of many sysadmin needs during my daily trips to the project team room, there were more than a few times that the development team needed the sysadmin (me) that wasn’t in the room with them.
But overall, the arrangement mostly worked. I was a member of the operations team working directly with members of the development team.
Perhaps we were “DevOps” before “DevOps” was cool? (Sorry, I digress.)
My point is there was no “wall of confusion” that stood between myself and the development team. As I’ve been learning more about DevOps, one of my learnings is that DevOps intends to address the “wall of confusion” that exists between development teams and operations teams.
Well, that’s confusing to me.
DevOps: What’s so confusing?
Where does a such a “wall of confusion” come from? Is it due to the lack of integrated processes or tools as some of the books I’ve been reading suggest? Perhaps. Back in the day, I was using different tools and had different access privileges than the development team. There were access privileges that the development team had that I did not. But, I wasn’t confused about what needed to be done, and who I needed to support.
Is it because of differing goals between the development team and the operations team? Maybe. But that’s not “confusion,” it’s lack of clarity about goals and objectives. When I was the sysadmin for the project, although I reported to a different manager, it was clear to me what my priorities were.
I would argue that if a DevOps “wall of confusion” exists between a development team and an operations team it’s because it’s allowed do so. Granted, there may be disparate tools, or over- or under-engineered processes between the two teams, or different reporting lines that may result in some challenges to getting things done. But if goals and objectives are clearly communicated, management actions match words, and if the teams have a “we-can-do” attitude, I don’t understand why a “wall of confusion” would exist.
We need each other
So why will adoption of DevOps (or insert your favorite methodology here) cause the wall to come down? The answer is that it won’t. While it may point out the issue, like everything, it’s how we as individuals decide to behave that will make the difference. If attitudes of “us vs. them” exist, there’s no methodology that will ever fix that. It always comes down to a personal choice.
The fact is that Dev and Ops (and IT service management (ITSM)) have always needed each other. Network switches, servers, and storage devices are just collections of junk without applications and software. Then software or application code are just wastes of effort if there is no underpinning infrastructure.
DevOps and ITSM: Tear down that wall
If the DevOps “wall of confusion” exists at your organization, it’s because you allow it to do so. And you can tear it down, and here’s how:
- Establish and agree what success looks like. This means that there must be open dialog between the ops and dev teams. Often teams get stuck because the team members aren’t clear on what “success” means.
- Be genuinely – and publicly – appreciative. When a team member puts in that extra effort and makes something happen, acknowledge their efforts. Words have meaning; words are given power when they are expressed in a public, genuine way. “Thank you” are two of the most powerful words that can be said to a teammate.
- Commit to being a learner. We each have talents and strengths that when added to the team, will drive the team forward. Openly and proactively share what you know, and learn from the talents and strengths of others on the team.
- Mistakes have to be “learning opportunities,” not invitations for criticism and second-guessing. Let’s face it – people are human, and humans make mistakes. One thing that is for certain – someone who never makes a mistake is someone who has never tried something new or different.
- Always find ways forward. When challenges and obstacles present themselves (and they will), don’t hide behind all of the reasons why something cannot be done. Challenges and obstacles often result in innovative ways for solving a problem. As a result, solutions are delivered and the team gets better together.
At the end of the day, IT will succeed or fail as a team. No methodology or framework alone will make success a reality. Success depends solely on the attitudes and behaviors of people. If a DevOps “wall of confusion” exists, it’s because people allow it to exist. The choice is yours – choose not to allow confusion to stand in the way of teamwork and success.