Tag: cross-functional

  • The complexity of communication: Are we all Masters of Disaster?

    The complexity of communication: Are we all Masters of Disaster?

    To better the communication between people in tech teams is one important issue in daily work. Although we all grew up with communication from our early childhood on, we know, that communication often fails. But what do we all do about this discrepancy? Why do we accept eyes wide open these frequently painful failures? Why don´t we really care about misunderstandings and their consequences? Are we all Masters of Disaster?

    The answer is: Communication is a very complex topic on both sides of the game – on the sender´s side as well as on the receiver´s. To get aware of what is going wrong in our communication we have to do some very hard stuff: self-reflexion (which is indeed sometimes painful and hard to bear), changing familiar behaviors and leaving the comfort zone. This is really hard work besides all the tasks of our daily job! Additionally to a strong will, we need persistence, patience and most of the time aid from the outside to be successful in changing our communication! But in the end this entire struggle is worth it!

    In DevOps teams, where “ship fast” is taken over from “ship faster” to fulfill the goals of “continuous of everything”, a well accepted and effective, but appreciating communication is the basic skill for success. This means that building a successful team is comparable with building a house: if you spend enough in a strong and solid fundament, it will carry the house you want to build on it for a long, long time. But you have to consider, which kind of house you want to build to develop the fundament.

    In cross-functional teams with high demands – those teams we actually find in the tech industry – communication is the fundament of whatever is built on it. Communication is part of the culture and it is the tool

    • people get in contact with each other
    • knowledge is shared
    • goals and visions are shared
    • feedback is given
    • failures and success are shared
    • appreciation is shown.

    People in such demanding environments need to trust and rely on each other. Or do you want to share your knowledge with someone you do not trust? The success of the team depends on the relationships between all teammates including the leader. Relationship and trust are built among other things through the way we communicate with each other. No it is time to say, that communication is not only what we are saying with the words we are using. Communication goes far beyond the meaning of the words. Remember “Cce” – Communication causes emotions! Even in the tech world, which is still a male dominated world, communication causes emotions and feelings – although lot of people may refuse this.

    With speaking about the complexity of communication it means that there are on the one hand three different parts of sending a message and the impact on the receiver. On the other hand there are lots of possibilities how to interpret the messages. Lots of possibilities – this seem to be a source for many misunderstandings! Now be aware that an immense part of our communication – sending as well as receiving – happens in our subconscious!

    Most probably you have heard about the three different parts of communication: the verbal communication and the nonverbal communication with its subitems ´paraverbal communicationand ´body language.

    The verbal communication is about the wording, the language, the syntax, the grammar and yes, it is also about the logic! There you are: “Things have to be logical, then everything is fine, isn´t it?” Sorry, but: “No, it isn´t!” It is even not half of the truth. Here is the reason, why so called one-track specialists often have problems to convince others, although everything they say is absolutely right and logical. At this point the nonverbal communication appears on the human playing area! The paraverbal part of communication contains facts like the volume, the speech rate and melody, the intonation and articulation and at least the tone of the voice. This is completed by the body language with the fascial expressions the gestures, the body posture, eye contact, body chemistry and the clothing. If the expression of all three components is the same – then everything is fine! If the verbal communication says “YES” and the nonverbal communication “NO” – then people tend to believe in the nonverbal communication because its impact is much higher than the impact of the words.

    Just one example at the end: at one of the DevOpsDays I have joined this year, I saw one young speaker. I guess, he is really an expert in his topic and the idea and content of his talk was excellent. But he didn´t manage to appear convincing and convinced: a wrinkled shirt, a loose jeans, unkempt hair, barefoot in his sandals, a lousy body posture and a bored facial expression. You can say that this is a superficial point of view. Maybe – but that is the way it works! Communication always needs a holistic approach – and seemingly superficial points of view are influencing the our feelings and the way we interpret messages! Or to say it the other way round: if you want to convince somebody and make her/him trust you, you have to focus on all parts of communication! It is the same when you want

    to share knowledge, give feedback or want to lead a team. Communication is more than just the words!

    In the next blog post you will read about the chain of communication!

  • DevOps across the Enterprise: Fostering Cross-Functional Collaboration

    DevOps across the Enterprise: Fostering Cross-Functional Collaboration

    DevOps practices originated at startups, where nimble Development and Operations teams pioneered the concept of cross-functional collaboration to speed up software release cycles. By 2009, DevOps became a recognized industry practice: a software development methodology that promised higher velocity for enterprises working to get products to market more quickly. Many enterprises have since embraced DevOps among their software development teams, and early adopters are now taking it beyond code to other parts of their organization.

    Unfortunately, successful cross-organization collaboration is uncommon outside of Dev and Ops teams. With the Internet of Things bringing software and hardware together in previously disconnected devices and industries, collaboration among design, development and product management teams has become crucial. There are technical, procedural and cultural challenges which must be addressed to bring the same level of DevOps success to other areas of an organization.

    The State of Collaboration

    An important place to start is understanding the interactions between different groups in an organization.

    Consider one of the most frustrating areas of the software release process prior to DevOps-style collaboration. Builds would be “tossed over the wall” from Development to Quality Assurance, and then from Quality Assurance to Operations, with each team moving on to other things as soon as a build was handed over. Visibility into the overall status of the project was non-existent.

    When other departments collaborate, what is the level of visibility into the work being produced by the groups that depend on one another? Does marketing know if the latest feature made it past the initial legal review and the likelihood of it being included in the final product? The answer is usually no; there is little visibility into the process and decisions are shared close to project deadlines. Applying DevOps practices to an organization’s entire product pipeline changes the collaboration paradigm, expediting time to market and improving overall quality.

    Culture, Automation, Measurement and Sharing (CAMS)

    CAMS is relevant when both technical and non-technical teams collaborate. As seemingly unrelated teams are required to work together, it’s important that they have a culture of shared accountability.

    Skipping the details of specific tools and technologies, one key consideration for organizations to recognize is that automation is crucial to a repeatable process, enabling speed and scale. It also provides a high level of visibility, as it’s closely coupled with the sharing of data. When only one team is manually updating metrics, communicating what’s going on is manageable. But what happens when other groups are dependent on work being produced by a group that’s updating its data manually? What if multiple groups depend on knowing the status of a task in a timely manner? Manual processes result in an endless flood of phone calls, emails or instant messages asking if information is up to date.

    The measurement aspect of DevOps opens up a can of worms. It’s important not only to determine what should be measured but also to have a common way of discussing how it’s being measured. Establishing a common vocabulary across an organization for day-to-day tasks can be extremely difficult.

    In these situations, it is important to go back to the core benefits of trying to bring the DevOps style of collaboration to other groups in an organization.

    1. What is the desired business outcome?
    2. Why don’t current processes meet requirements?
    3. How could change positively benefit employees’ daily work?

    As people become comfortable with “why,” discussions of “how” become easier.

    Once changes are underway, it’s important to make sure that there is a single place where people can obtain accurate status updates and share information. Bringing DevOps into the enterprise takes time, but providing visibility into any project in an automated, transparent manner will show the positive impact of sharing information in a timely way.

    Most importantly, try to quickly demonstrate success—however small. There will be roadblocks, political objections (an unfortunate reality) and people who just don’t want to change. But by measuring and demonstrating success and tying it back to business outcomes, you will set up your organization for success.

    Like many other initiatives, the key to a successful DevOps program is intention. To drive this home, an old joke: how many therapists does it take to change a lightbulb? Just one. But it has to really want to change.

    About the Author/Jonathan Thorpe

    jonathan_thorpe_origJonathan Thorpe, Technical Marketing Manager, Perforce Software –Before joining Perforce as a Technical Marketing Manager focused on Continuous Delivery and DevOps, Jonathan Thorpe held technical marketing roles at CFEngine, Serena, and Electric Cloud, where he specialized in DevOps culture and automation technologies. In his spare time you can find him reading, playing with all of the current video game consoles, dabbling with mobile software development, and playing with the Raspberry Pi.