As the unofficial ambassador to the DevOps community from Product Management, I recently attended the DevOps Enterprise Summit in Las Vegas (#DOES18). I presented on the relationship between Product Management and DevOps and attempted to help DevOps understand more about the world of Product Management. You can watch a recording of my presentation online here.
While there, I caught up with Ajay Chankramath of Oracle and chatted with him about his journey in DevOps and the handshakes between Development/Quality/Release/Operations (DevOps) and Product Management. Below is a summary of our conversation. Ajay makes the case for a tighter handshake between DevOps and Product Management to achieve the goal of delivering the "right" functionality faster, more efficiently, and more reliably.
LF: What’s your role and remit at Oracle?
AC: My name is Ajay Chankramath and I am the director of development operations for Oracle's Marketing Cloud platform. My remit includes the platform development, release management, the build and test platform with continuous integration and continuous delivery. The scope of the platform development is fairly exhaustive across the overall DevOps value chain with monitoring, analytics, telemetry platforms as well as pipelines for container orchestration. As a large established organization, we are adapting to continuous integration/continuous release that is the promise of DevOps.
LF: How would you characterize the maturity of your DevOps process?
AC: Overall maturity level would be somewhere around 3 on a 5-point scale. In terms of being a data-driven process, I would say we’re operating at a 4/5.
In terms of platform release work, we are fairly sophisticated closing in to the top of the maturity scale. I hesitate to refer to the platform release process as “DevOps” because I’ve seen that team members think certain aspects of the process are not their responsibility or don't consider it their role in facilitating it to be efficient, from where they sit.
On the deployment and delivery side, we're probably operating at a 3 on a 5-point scale. Continuous deployment is the goal and we need to put some more systems of improvement in place to ensure that all our deployments have zero customer impact.
Ideally the product owners should have a holistic view of the end-to-end requirements-development-delivery process of the feature.
The biggest challenge that we have is around the ownership of the end to end pieces. Case in point, Product Management talks to the customers and they may tell Development, “Hey this is what we want,” and then assume that their job is done. They then ask Product Development, “Just tell me when the feature is going to be ready.” Promptly, Development will start writing the code without consideration for certain parameters or the environment in which the solutions is going to be run. By the time they think about it, it’s too late for a large hierarchical organization with command and control structure with multiple levels to react in an agile manner.
Product Managers, in most cases, think that others downstream in the process will figure out the challenges with this inherent lack of agility as we try and productize their stated requirements. Instead, we can do a better job if someone, ideally the product owners, maintains a holistic view of the end-to-end requirements-development-delivery of the feature. This will ensure that the customers and the employees are equally happy and productive and reduce the need to have too many heroes on the team to save the day when things don’t work as well as expected.
LF: Can you share a case example of where the Dev/Ops/PM relationship could have worked better?
AC: Sure. A good example of how things were not working optimally was when we wanted to introduce a new usage pricing model and needed to meter depth and breadth of customer usage of the platform. At the time, we had about 1M transactions and up to 2,000 customers on the platform.
Product management specified the feature to be developed and made the request of Development. As Development began designing the feature, they consulted with System Architecture team about the optimal approach. Now Architecture often thinks about the "best possible" solution but not always the most pragmatic approach. Turns out that the approach recommended by Architecture required purchase of additional storage systems for which there was no budget.
Development did not consider this and assumed that the operations team would solve for this. This became a problem downstream and ultimately resulted in more cost and delay to the pricing capability released to the market.
Product management often thinks, “I can tell you what I need, you figure out how to implement it.” After the requirement is delivered, Product Management expected that DevOps would deliver on the commitment in the agreed timeframe but didn't really consider what was involved from an architecture standpoint and didn’t specify any additional parameters for operationalizing the capability. As you can see, there are way too many handoffs between so many teams with autonomous charters within and outside of the lines of business. Whenever there are extensive handoffs it is important to have a champion (ideally Product Management) who can shepherd such processes.
Granted this is scratching at the surface of the DevOps culture, however larger, long established organizations who have been as successful as we have been now need to discover and build more pragmatic migration paths to the new world.
In the ideal world, each group has a primary focus but with a shared responsibility.
LF: How would you like to see the DevOps-PM handshake evolve?
AC: I’d love to see the improvement of the optimal path to production. People think we are doing great because everyone thinks, “I did MY job.” The mindset change we need has more to do with, “We did OUR job.” Individuals rely too much on the assumptions of the process, but who oversees the end to end outcome? Perhaps when the process is highly evolved on the maturity scale we can rely on it more with less explicit oversight, but as it’s being developed, the end to end responsibility is important.
Ideally, I’d love to see my VP for the Product Owners and the VP for Product Development doing a joint presentation at an upcoming conferences on how we have evolved into a well-oiled delivery machine and on how they are working effectively together.
In the ideal world, each group has a primary focus but with a shared responsibility. Development doesn't just code, Operations doesn't just run the system, and Product Management doesn't just specify high-level requirements. There needs to be a tighter level of ownership and coordination of every step in the path from concept to cloud. Velocities of sprints and releases should be more of a holistic view as opposed to time-to-code and getting a feature onto a branch. Velocity should be measured and more importantly allocated, as code-to-cloud activities.
People think we are doing great because everyone thinks, ‘I did MY job.’ The mindset change we need has more to do with, ‘We did OUR job.
LF: How can Product Management help DevOps?
AC: Product Management can really help by educating DevOps on the business objectives that are to be accomplished and better understand the upfront parameters associated with specific requests like example given earlier.
Ideally Product Management can get more involved in really understanding the Optimal Path to Production process and where it might be appropriate to apply more inputs. That way they’d be able to better anticipate some of the critical interdependencies and the kind of guidance that they really need to provide to the Development, Quality and Operations teams. Product Management doesn’t need to understand , say, how to deploy to a Kubernetes cluster or how to ingest data onto InfluxDB. Instead, it will help us all in DevOps if Product Management understands more about deployments and data management and the dependencies around it just as important as the actual code to implement it.
As we travel down the process maturity path, Product Management could also really provide some oversight for the journey of their requirements from their concept through to cloud deployment.
LF: How can DevOps better engage with Product Management?
AC: The Development and even the Operations teams could really provide feedback earlier in the process where Product Management has the opportunity contribute more insight into the capability under development.
In the planning phase, the feedback provided to the Product Management should be more of a holistic view of what needs to be done as opposed to just planning for the code development. As mentioned earlier, the cost of a particular feature for the latter could be, say 8 story points, but when you add the operational enablement component that could become a 16-point story which gives a much more realistic view of the world. This is also where the DevOps culture in Product Development can help Product Management by having concepts like site reliability engineers (SREs) embedded in the planning processes. I presented on this very topic at #DOES18 in Las Vegas in my presentation, “Reliability Engineering (RE) DevOps Transformation,” which you can watch here.
LF: How can Product Management benefit from deeper engagement with DevOps?
AC: Product Management can definitely benefit from deeper in engagement with the DevOps teams and processes to understand how it works operationally, understand the handoffs, and understanding the key points along the process where they can collaborate and add value to ensure that they get the capability delivered to the marketplace in the time expected and ultimately deliver on the value they intended.
While there might be a short-term price to pay in reduction in velocity, that will translate to better predictability and reliability which are the hallmarks for a great product that PMs can be proud of and that enhances their standing in front of their customers.
LF: Anything additional to add about the partnership between DevOps and Product Management?
AC: Often, heavy-handed process can seem restrictive and slow. We all understand the goal of achieving fast and efficient release process, reducing outages and increasing customer migrations. With that said, the optimal way forward is to connect regularly across Dev/QA/Release/Ops/Product Management and debrief on where things do go wrong, assess how the flow is going against our KPIs and analyze where some of the break points are to achieve an environment of continual improvement.
Many a times, formalizing an assumed process that is in place helps the team understand the bottlenecks and can eliminate steps (e.g.frivolous control board reviews) and introduce some others (activities like launch readiness reviews).
LF: Thanks for taking the time to share your experience. Best of luck on the journey ahead.
AC: My pleasure. Good chatting with you.
Learn More About XaaS Product Management
It was a pleasure chatting with Ajay. The handshake with DevOps is part of TSIA's XaaS Product Management research practice, so please contact us today to find out how we can help you better optimize your Product Management team for the future of XaaS.