I’ve noticed a trend amongst all the companies I work with and have interviewed, over 30 in all. That trend is the breakdown of communication, collaboration and empathy. The intent is not normally centered around vitriol but rather it is a lack of understanding and willingness to understand. The two groups at the center of this trend both want to be great at their jobs and want to do what is right for the organization. They genuinely want to be seen as helpful and successful and always doing the right thing. The problem is that the “right thing” for each team in a vacuum is not always the right thing for the other. Aren’t we far enough along in DevOps to have seen most of this be resolved? Most of the time my answer would be yes. In this case, it is definitely yes because it isn’t Developers and Operations that I am referring to. It is the business and developers.
DevOps is (for me) at its core about culture. It is about building relationships that allow sharing of knowledge in a transparent and open fashion. Since we often judge ourselves on our intentions and others on their behaviors, having this relationship smooths out the transition from misunderstanding to alignment. Knowing a person before a conflict helps us to understand their intentions and have the freedom to ask when we don’t know. This is as true for DevOps as it is for any inter-team relationship.
Defining “The Business”
For the sake of this blog post, I’m splitting the business up into three parts.
1. Business Leadership (CEO, CIO, CTO…)
3. Product Management
There are certainly other representatives that make up the business, however these are the three that seem to come up time and time again with my conversations with organizations. We are focusing mostly on the parts of the organization that help feed feature requests into the pipeline and require specific forecasting from developers. They are also a major part of the overall Value Stream Map.
The Core Problem?
There are really a couple of issues that are contributing to the bottleneck between the business and the IT teams. I will address each one as I have experienced it.
1. The business doesn’t understand the IT teams and the IT teams don’t understand the business.
2. There is a distinct (and often overt) lack of empathy between the teams.
3. There is little to no communication between the teams, and what communication that does exist is done with minimal effort.
Lack of Understanding, Empathy and Communication
In my interviews with product managers, business leaders and developers I am often met with statements like the following:
Lead Developer: “Product Managers have it so easy. They only have to take customers out for drinks and chat and then promise them the world. We are the ones that then have to make those unrealistic dreams come true with no additional help, money or time. Must be nice to have such a cush job.”
Product Manager: “The developers are such whiners. They don’t have to deal with the hassle of managing customer expectations or travel and they get all the best stuff. They only have to write a few lines of code, and do so in the leisure of their homes half the time! They have no idea what a real job is.”
Business Leader: “We’ve got a huge customer wanting this product/feature. We have to make this deal or we may not make our numbers for the year. We have done something similar in the past so I know we can do this again. Sometimes we have to work weekends and sacrifice for the good of the company.
This lack of fundamental understanding of what other teams do, how they do it and how it contributes to the overall success of the organization is wide spread. Even when teams attempt to share this information it is lost in the fog of war, and ends up creating more mistrust and angst. A large contributor to the problem is the lack of empathy across teams. It can be very easy (and tempting) to arm-chair-quarterback. It is very important to work towards creating a culture where we respect the difficulty and contributions of other teams. One of the best ways to begin this journey is by working to get the lines of communication open between teams.
Ok, yes that’s obvious, but how do you actually DO it? Most of the blog posts I see are really about high level problems like these, and they stop at the point of telling you what you already know… your culture is broken and it doesn’t feel right. So let’s talk about specific ways I’ve seen work at tackling these problems.
Consistently Missing Due Dates
I’ve gotten a lot of feedback from leadership regarding their concerns for missed due dates for products and/or poor quality around products. The business leadership really doesn’t understand how this could be happening. In many cases it stems from “scope creep” during the sprint. We see the work being done during that sprint growing well beyond the original planning, with product managers pushing more work into the pipeline mid-stream. There is no room or authority for pushback on the product managers, so in order to accommodate the additional work, corners get cut. The incentives drive the behavior, and in this case it is being judged on how many features are getting to market. Without including a focus on quality and velocity, you end up with a similar situation to teachers being judged on grades achieved rather than knowledge learned.
The business must focus on proper prioritization of features, projects and products first. Accept the tradeoff between work that can be accomplished and set quality standards and resource constraints. Continuously bang the drum of “slow down, do less, accomplish more”. This will keep the scope creep in check and allow for the completion of projects with a higher degree of quality. You can start with a time-boxed approach to this, like an experiment. If you are tracking your velocity and other metrics prior to the experiment, try it for a few sprints and compare. Don’t forget to include metrics outside the dev teams too, such as support cases and customer feedback.
Performing demos at the end of sprints can be a great way of showcasing achievements and progress. It is also a great time for feedback on the product and process. However, in many cases the dev teams were not inviting anyone outside of their scrum teams. When I asked why there was no one from the leadership team in the demo meetings, I was told they didn’t really get anything from it. When I talked to the leadership, they stated that they didn’t understand the technical details of what was being said.
I took the approach of the TL;DR and Executive Summary. I worked with the developers to have a short session at the beginning that was more high level and based more on functionality. We took an Agile Standup approach to it as well:
1. What were the inputs and requirements for this sprint as understood by the devs.
2. What was accomplished and then showcased.
3. Asked for feedback from the leadership.
We iterated over this approach fine tuning the inputs based on the feedback from the demo. In many cases we started to recognize that the requirements from the business were not aligned with what the devs thought. These sessions included leadership, BA’s, Product Managers and the devs. We began to have more open transparent conversations and work towards bringing the BMVP (Business Minimum Viable Product) and the TMVP (Technical Minimum Viable Product) to an aligned MVP. It took work from all teams, but the results were amazing. No one was intentionally holding information from others, but that was what was happening. Breaking down the communication barriers meant we had a unified team from input to product.
More coming in Part 2…