A while back, I worked for a very large, international IT consulting firm. We did big projects for big companies...
-- banks, insurance companies, investment firms and large-scale manufacturers. At one point, when talking with a project manager, I heard something that surprised me. "You know, each day before I go out the door, I have to put on the armor," he said. I was surprised by his honesty and surprised I knew about the armor too. I put on the armor back then. We all did.
The armor is the psychological protection DevOps teams put on to make themselves impervious to the emotional slings and arrows that went along with the work done. The armor takes different forms for different people. For me, the armor kept up my guise of technical confidence, even while I felt incompetent. It was heavy, and we wore it
The armor and DevOps?
It may sound crazy, but the armor and DevOps are related. The values and principles found in Agile are inherent in DevOps teams. Agile work is done by a unified group in a transparent manner. It is about continuous improvement as opposed to ultimate achievement. We don't pin our hopes or careers on a single, big, perfect release. Rather, we get better over time by releasing new features often.
Quite a number of products have evolved around Agile. Just about all the project management tools support stories, backlogs, points, sprints and burn down monitoring. The tools integrate source code branching, merging, automated code escalation, automated testing and even automated deployment. Agile has proven to be largely effective; there really is more software that gets into the hands of users faster. But, for all the reported successes, there are still failures, particularly in corporate IT. Why? The theories abound.
My suspicion is this: Most of us still wear the armor. Instead of promoting unity and transparency among DevOps teams, the armor shields us from the world. But the act of software development depends on clear, accurate, continuous communication. When meaningful communication diminishes -- even at the personal level -- the risk of failure increases.
So, what's to be done? The answer is obvious. Shed the armor. The question is how?
Shed the armor
One way to do so is described in the book Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision by Jim and Michele McCarthy. The book specifies a set of protocols -- techniques, if you will -- that enhance workgroup performance in the pursuit of making great software, from product design to release
The Core Protocols focus on the emotional-cognitive aspects of group-based, creative activity. They provide a framework for project execution based on meaningful, personal engagement. No project management tool is going to prevent failure when the minds involved in the project are emotionally absent from the work at hand. The Core Protocols provide a way to do creative, meaningful work in a corporate environment without having to put on the armor in order to get through the day.
The benefit of personal alignment
One protocol is personal alignment. Personal alignment starts from the premise that before anybody can work in a group toward a specific goal, each person in the group must have a clear understanding of what he or she wants from the work at hand. It makes sense. Each of us wants something out of life on a day-to-day basis. If we're starving, we want food. If we're lonely, we want company. Wanting never really goes away. Rather, as our primitive needs get met, other wants emerge that are more subtle, complex and harder to identify. Abraham Maslow described this dynamic in his 1943 paper, "A Theory of Human Motivation."
Satisfying wants and desires is an important driver in human endeavor, even when we are on the job. The trick, in terms of creating a high-performance workgroup, is for each member of the workgroup to become aware of what he or she really wants from the work at hand and then to align one's actions to meet it.
According to the Core Protocols, once a person identifies his or her want and aligns himself or herself accordingly, the next step is for each member of the workgroup to share this personal alignment with the group. You then ask for help from each member bringing the alignment to fruition. DevOps teams commit to
I can attest from personal experience that the Core Protocols offer a compelling, effective way to work. The process of personal alignment was quite illuminating for me. Back in the days when I was involved in large-scale corporate IT, I thought my desires centered on material gain. I discovered otherwise. And being able to shed the armor and share my personal alignment with others was an emotionally emancipating experience. (For what it's worth, my personal alignment meant wanting to feel accepted.) As a result, I felt more in sync with the other members of the workgroup. I found that I looked forward to coming together to do work. The others reported feeling the same. I like to think our product and our process improved. By all reports, it did.
Put it all together
DevOps and Agile have changed the way software
Our tools have improved to reflect the new sensibility that comes with DevOps teams. One of the last pieces of work to do to improve DevOps is to implement the structures and techniques that get all of our minds "in the soup." There is absolutely no downside to developing workgroups that can think clearly and creatively together in a continuously improving manner. The Core Protocols can go a long way toward fostering such a work environment. Personal alignment is the place to start.