ProdDev: the New DevOps?

This article is featured in the new DZone Guide to DevOps. Get your free copy for more insightful articles, industry statistics, and more! 

It’s a theme heard regularly when discussing the software development process: “I wish A and B talked to each other more and each had a deeper understanding of what the other was doing. If only A and B were incentivized to work together, rather than ‘throwing work over the wall’ from one to the other, things would be so much better.”

A = “Dev” and B = “Ops” is probably the most well-known current version of this theme. At the level of individual teams, though, I’d contend that the issue of “throwing work over the wall” from developers to Ops is, if not quite a solved problem, then at least a problem with a known set of solutions.

This should not be taken to imply that developers and Ops now necessarily understand each other’s work or mentality much better. Rather, the increasing availability and maturity of cloud IaaS offerings and services provided on top of them, means that detailed knowledge of operational “secret sauce” is now required in far fewer cases. At least for straightforward applications that are not (yet) pushing the envelope, scalability, resilience, automated deployment and management, etc. have increasingly become out-of-the-box experiences.

There is a different phase in the software development lifecycle, however, where “throwing work over the wall,” low levels of communication, incomplete mutual understanding, and, not infrequently, misaligned incentives are still common. Product Management and Development teams often communicate only when descriptions of features to be built are thrown over the wall (a.k.a. “handed over”) in the form of requirements, documents, or items on the product backlog. Ongoing dialogue to explain and fine-tune the motivation for these features is rare, and is additionally complicated by the lack of a shared, up-to-date model of the needs of users and the position of the market in general. More fundamentally, a clear shared understanding of the roles of Product Management and Development in ideation and feature refinement is often missing, and the respective views of how much value each group adds to the overall process and product differ quite substantially.

Why We Need "ProdDev"

OK, so for argument’s sake, let’s say there indeed is still is a “wall” between Product Management and Development. Why is this a problem? If DevOps makes the “how” part of building software that runs reasonably well so much easier, what else do we need?

In the first place, it’s worth noting that many companies, and certainly most of the leading tech companies, place a strong emphasis on their core values on user-centric thinking, or “putting the customer first,” in their core values. That user or customer, in general, doesn’t care much about how easy it was to build the software they are using. They may care about how quickly the software can be updated to meet new needs, and this is an area in which adopting cloud and DevOps practices definitely helps. More than that, however, they care about what is being built –what the software they use actually does and how it makes their lives easier. In most cases, this is far more important to users than the speed of development: a clumsy feature delivered a week early causes many more problems than a great feature delivered a couple of weeks late.

Of course, getting the “what to build” question right is genuinely a Very Hard Problem, as anyone who’s had to wrestle with product/market fit will attest. One study of a widely-used piece of software showed that about a third of new features genuinely improved the user experience, a further third had a broadly neutral impact, and the remaining third actually made things worse. Whether these proportions are fully representative or not, it seems evident that the more of the team’s intelligence and creativity that can be harnessed to tackle the problem of what to build, the better.

Why then have only one person, or a couple of people, work in relative isolation and show up at the beginning of the project or sprint with a list of features or user stories that the team “just needs to implement?” Why discuss the underlying user needs that provide the critical background to the intended features just before work on them is about to start? Why use synthesized and abstracted “user personas” instead of personal interactions with real end users?

Obviously, researching the market, talking to active and potential users, and defining and validating coherent feature sets that address genuine user needs are usually full-time activities. Expecting a development team that’s trying to get “into the zone” for maximum productivity to be engaged in all of these tasks would likely be very disruptive. Luckily, there are a number of relatively low-friction activities that can be incorporated into the team’s routine fairly easily, and which can start to bridge the “Prod-Dev Gap:” regular user interactions, early backlog insight, review of user-level metrics, and access to user feedback.

Regular User Interactions

As long as users are represented by synthesized and somewhat “faceless” user personas, creating a sense of empathy within the development team for their applications’ users is difficult. Developers, as expert users, are also often at risk of not understanding how or why users fail to “get it” when features turn out to be much less usable or useful than intended.

Arranging in-person contact between developers and users can be difficult, especially if the user base and development teams are geographically separated. Presenting profiles of individual users to the dev team on a regular basis; ensuring the team gets to interact with users during meetings such as Customer Advisory Boards; encouraging attendance at conferences, meetups, and similar gatherings; or even just reporting back to the dev team about meetings with existing or potential users: these are all steps that can hopefully be taken without too much difficulty to increase the team’s feeling of being “close to the user.”

Early Backlog Insight

In many organizations, “grooming the backlog,” i.e., ensuring feature requirements are appropriately prioritized and are described in sufficient detail to be worked on by developers, is the “upstream task” of Product Management alone. As a result, much of the information about the market, identified user needs, and competitive positioning that goes into determining why a particular feature is needed and why it is considered to be more important than other features, remains largely hidden from the dev team.

Short, regular sessions where one or more developers review the pipeline of future product work can greatly increase the development team’s level of insight into the ideation and feature refinement process. For example, a group working in two-week sprints could schedule a bi-weekly session in which a rotating member of dev team meets with the product manager to review what’s likely to be coming up two to three sprints down the line.

In addition to providing early input into any technical challenges ahead, such meetings can help ensure that developers have a better picture of which user needs are being investigated, and also gives them the opportunity to suggest possible alternative solutions.

Review of User-Level Metrics

It’s common for standups and other status meetings to review burndown charts and similar development status metrics, but taking a quick look at how the application is doing from a user perspective is something that usually happens much less frequently, if at all. Often, a necessary prerequisite involves defining and collecting metrics that actually relate directly to the user experience: for example, checkout processes abandoned, user-experienced load time, or time taken to complete a particular user flow.

Part of the challenge here is that — unlike low-level operational metrics such as CPU usage or API error rates — user-level metrics are, in most cases, not provided out-of-the-box by cloud platforms or monitoring tools. Instead, measuring and publishing these metrics has to be explicitly coded into the application, while the appropriate scripts and dashboards to analyze and visualize the results also have to be created by hand.

Still, dedicating a particular timeboxed amount per iteration to improve user-level metric gathering and reporting for your applications is a great first habit to adopt. This is as much due to the increased focus on user-level experience as it is the result of any particular metric captured or dashboard created.

Access to User Feedback

If there is a recognized support channel for the team’s applications, exposing developers to support interactions can be a great way of putting them in touch with users’ day-to-day questions and experiences. At the same time, inundating the development team with support requests to the point that they’re no longer able to work effectively needs to be avoided.

Practices that are worth exploring include regular review sessions of recurring or noteworthy support issues conducted by rotating members of the support and development teams, and “Stack Overflow” or “forum duty,” where a rotating member of the development team spends a fixed amount of time responding to user questions.

A chat channel or status board that displays ratings, feedback comments, or similar indicators of user happiness to the development team can also be very useful. Care needs to be taken, however, that such an information channel is not so “in your face” as to become an ongoing distraction — such as a channel that alerts all members with a visual notification forevery message.

On Misaligned Incentives

“ProdDev practices” like those described often sound sensible in theory, but from experience, we know that much more is needed to actually make them work in real life. One key lesson from numerous attempts to introduce DevOps is that little is likely to happen if the practices conflict with fundamental differences in how the respective groups are motivated.

One way this misalignment can manifest itself between Product Management and Development is if developers are encouraged (through internal attitudes, promotion culture, etc.) to aim for technically complex and “sophisticated” solutions, rather than aiming for The Thing That’s Best For the End User. Since this question often goes all the way up the food chain and ultimately revolves around (re-)classifying IT as a business rather than a technical function, it’s unfortunately generally not one for which there are straightforward solutions.

It’s worth noting, though, that a focus on technical sophistication and complexity is rarely aligned with most organizations’ professed focus on the user or customer. Therefore, the question“how does this ensure we build the best solution for the user?”can hopefully at least become a talking point when team goals are under discussion. Also, the more the team is able to adopt some of the ProdDev practices presented, and the more regularly they are exposed to users and user-related metrics as a result, the more the team will habitually define and measure success in terms of user satisfaction rather than via technical achievements.

Conclusions

With DevOps, we have developed a whole bunch of techniques to help enable teams to build software better. With the creative capacity that this has freed up, we can hopefully now focus on leveraging the skills, ingenuity, and intelligence of the entire team— not just of an “upstream provider” in Product Management— to tackle a far more challenging problem: how to build better software, software that our users really want and need. Let’s hear it for ProdDev!

This article is featured in the new DZone Guide to DevOps. Get your free copy for more insightful articles, industry statistics, and more!