DevOps is Old News. DevProd is the Future

Source – devops.com

DevOps has been widely embraced and isn’t going away. However, there’s a new software movement emerging that deserves headlines of its own. Let’s call it DevProd.

In a recent Harvard Business Review article, “Agile at Scale,” the authors point out that “conditions are ripe for agile teams in any situation where problems are complex, solutions are at first unclear, project requirements are likely to change, close collaboration with end users is feasible, and creative teams will outperform command-and-control groups.”

To understand why DevProd may be the next big thing, some perspective on the DevOps movement will first be helpful.

DevOps Addressed a Huge Pain Point

At one time, software was often created by a single person. By 2008, teams of hundreds or more were needed to meet the accelerating complexity of software development. We hit an inflection point, triggering an organizational need to streamline and fuse development (code) and operations (IT infrastructure).

Companies were scrambling to “go agile,” but silos between these constituencies became roadblocks. In response, DevOps, which was coined at the 2008 Agile Toronto Conference, broke down those silos and had a profound impact on a company’s ability to move faster and more efficiently.

Waves of companies and products soon enabled streamlined processes between developers and operations. Some became successful, such as AppDynamics (acquired by Cisco Systems), Splunk, Chef and Puppet.

Today, while there remains room for improvement, this challenge is largely resolved. Companies have added DevOps experts, while DevOps tools are embedded in development and operations processes.

History Repeats Itself

As part of my job, I often speak with leaders of software development organizations. Once the conversation turns toward development speed, app deployment or even features management, executives will invariably mention the product manager—that is, if she isn’t already in the meeting.

When I realized this was happening with startling regularity, I began to wonder, Why involve the product manager in a conversation around development and deployment?

Just like with DevOps years ago, organizational leaders from various disciplines within the same enterprise are suddenly working closely together. There is a movement underway, with the purpose of creating feature-based teams that are organized around a single aspect of a product. The purpose of the teams is meant to break down silos by bringing together disciplines such as engineering and product management. A great example of this is Spotify, a company that created the ultimate #squadgoals approach to enterprise agility by breaking down core organizational units into smaller, autonomous product development team with no more than eight people. Each team or “squad” is accountable for a discrete aspect of the product, from cradle to grave. The company shared some fascinating videos on their engineering culture.

Why DevProd? Why Now?

Of course, organizations require speed and agility. Product management requests changes and technical staff implements them. It makes sense they would need to work in close proximity.

Even though that’s been true for years, there’s still been a dramatic uptick in that collaboration.

With DevOps, companies increased deployment agility and reduced version release times dramatically, allowing them to stay competitive and react more quickly to the market. Yet, the DevOps movement retains a focus on an engineering unit: “the version.”

However, software versions are no longer as significant as they once were since full application distributions are no longer needed. Instead, every change to the application can now be considered a feature and can be rolled out separately and in more granularity. DevProd is to continuous software delivery what DevOps is to version updates.

Developers and product managers have different priorities. Developers think about impact on the broader application and compliance with technical requirements. Product managers think about impact on business KPIs and how to determine that impact. If either group works in a silo, the other group can’t achieve its goals. Instead, they’ll need to work together much more often. That’s DevProd. I’m confident DevProd will have the same, if not more, impact as DevOps did. I know this because the pattern is the same:

1. Companies try to solve a burning issue and spend resources on developing the solution in-house (e.g., what IT did with log management before Splunk).
2. They continue to spend resources on evolving and maintaining that solution.
3. The solution has a real impact on the company’s ability to meet its business goals
4. The C-suite in that organization buys into the vision and is willing to take ownership of it and assign resources to it.

It Won’t Be Easy and May Not Be Enough

It’s an exciting time to work in software, and the fusion of development and product will deliver immense benefits for organizations. However, the DevProd movement is not without its challenges.

Regardless of how closely they work together, project managers still need the development organization to create experiments and custom experiences. They cannot simply wish them into existence. Because developers will run experiments of their own (improving application performance, using new tools, etc.), it won’t be easy to juggle the business and development-focused experiments.

All experiments need to be well-coordinated and carefully planned. That will become a necessity as organizations respond to a market that is feature-centric, not version-centric. Features need to be easily controlled and managed in production, by both developers and product managers, without overstepping each other’s actions. Moreover, the need for speed requires product managers to manage features with a click—without creating additional work for developers. At the same time, developers need to be assured that changes don’t break the application or hurt performance.

Developers and project managers working closely together is necessary step toward solving these challenges. But it may not be enough. In fact, almost every company I talk to has either developed or is contemplating a single system that will allow both developers and project managers to run some level of experimentation.

Larger companies such as Facebook, Uber and LinkedIn even have developed highly sophisticated experimentation systems in-house.

What This Means for You

It’s an exciting time. It is not that often that you witness a movement that gives rise to a new product category that will evolve over time and create a substantial impact.

For companies to stay competitive, they will need to:

• Create a DevProd virtual/actual team to align their feature deployment plans as well as share ongoing insights from current deployed features.
• Implement a feature management platform that provides both control and visibility into the feature deployment and impact.
• The platform should be implemented by engineering and used by both Engineering and Development.