Now on Now: How we improved developer productivity by 20%

Good afternoon, everyone. How's everyone doing? Perfect, thank you. Welcome, for today's session, we are going to share our journey, "How did we improve developer productivity by 20%?" So lemme introduce myself. I'm Raj Palorkar, VP of Application Development for ServiceNow DT. DT is a group of people or team, who take care of developing technical solutions for ServiceNow business. Similar to you, we are customer zero. We implement ServiceNow practices for our own business. My team specifically focuses on digital properties like Now Support and Now Learning. Joining me on stage today is Amjad. You wanna talk about that? - Hey, hi everyone, this is Amjad here and I am Senior Director of Research and Development at ServiceNow ID. And I'm responsible for delivering the developer experience for our own internal developers, and managing lot of implementation on Now platform. Thank you. - Thank you, Amjad. So before we go any further, I have some questions for you. How many of you tried DevOps for improved productivity? Some show of hands, please. And how many of you actually heard developers hate DevOps transformation? Anybody? I can see some gentlemen smiling out there. But exactly same question, we started this journey two years back, would we be successful or not? And we are so happy that we made that investment, because we are seeing the results. We are able to completely transform a DevOps organization and today, we are gonna share lessons and tips from our journey. Hopefully, you can utilize in your organization to get some results out there, all right? So our goal is to make developers happy. You may be thinking that this topic is really about developer productivity, but a simple thing is that, developer productivity was a byproduct of making developers happy. So when we started this journey, we kept our people packed, ServiceNow people packed, which says that, "If you are living your best life, doing your best job, our purpose will fulfill automatically." So while we are focusing on our future, we are looking at how we can make improvement over developer's life out there, which was very, very fundamental to us to a journey out there. So the main thing was instead of taking this approach top down, which most of the organization do, we decided to take the transformation bottoms up. We created multiple developers engagement group. Think about we run around 600 developers all across the organization, multiple groups, engaged with them almost three weeks, took interviews. Focus was simple, "Tell me your pain points, gimme something how we can improve your life." So while we are focusing on the improvement, one good thing happened was, people thought something is big going to happen. The excitement that you generated allowed us to create developer community. We learned so many things out there, which became fundamental for our program and we learned a lot in this journey. You'll find something similar in organization as well. Our developers, we have coding tasks and there's so many non-coding tasks. How many of you heard a developer coming and telling you, "It takes me two days for development and 10 days to move to production." All of you agree on these aspects of it. The case is very simple thing. Think about a code checker script, which is nothing but ServiceNow best practices. Security, compliance, the script is running just before deployment. You're finding an issue, install deployment, go back to drawing board, do development, do testing again. So the time waste. And as a developer, we love testing, right? Since we did transformation, we found developers are also doing testing and they hated testing. Automation testing, automated tools are there, but they were not focusing on the failure rate. It's much easier to fix the automation test, but let's do manual work and get it done out there, to spending so much of time there. All of us work on complex environments, 30 different environments. Think of integration testing. They were spending days to figure out configure data set out there, and our developers hated it from the depth of the heart. Other thing which became a common theme, everybody said, "Hey, GenAI is coming. New technology, I want to learn seismic. I want to do this. There's no time, I don't know what to learn around it." So using all this input, we created a three-pillar approach, which was really, Enable, Simplify, and Equip. Enable, it may look very simple about focusing on learning. We just did not focus on what to learn. We also focus on how to learn. In terms of what to learn, we could connect individual career growth with the learning that goes on top. Talk talks about certification, talks about latest knowledge sharing out there. How about we actually created the moment where innovation sprints are part of deliverables once a quarter, entire day spent on learning, every month learn and share till days where you could learn and tell your fellow members out there. Very, very popular out there. Simplify. Simply focused on dissecting entire SDLC lifecycle, breaking it down, finding out which are the process which are redundant out there. Look for opportunity which can be automated altogether. Equip. Obviously, focusing on the tools that technology to let developers do their job in the most efficient manner. Some more details will be shared by Amjad on these boxes. - Thank you, Raj. So as Raj pointed out, the focus was not just, you know, solving for DevOps, it was creating a holistic program, looking at the corners that we normally miss, learning process, and then really looking at the tool sets equally. So now let's dig into each of them one by one. So why did we focus on learning? Let's talk about that. Learning is integral part of how you look at your developer audience, because everybody wants to grow, everybody wants to be on the cutting-edge of the technology. So how do we solve for it? We wanted to create a cohesive learning program that focused on skill-based learning, understanding how much gap there is today within developer's knowledge base by understanding even their coding patterns. Like for example, if we are discovering opportunities of, you know, different codes written in different way, how do we bake that into the learning plan? Then focusing on enabling managers to carve out time for developers to actually focus on learning at some point in time. And then we also made sure that it's not launching a learning plan or a path. It is about sticking to it from a perspective of great onboarding for developers. Making sure that we really understand how to create a Learning Path based upon where individual is currently in their life cycles. And then not just launching it like one off case but making sure this is a, like iterative process integrated into their quarterly growth conversations. So it is not like, "Oh, this is a program and this is a learning path for you, but this is how you grow at ServiceNow and this is how you become a good developer." So we focused on learning as the first pillar of how the DevOps should be run or developer experience should be running. We did one more interesting thing. We align all of our career growths that you can see from IC levels to certification paths. Because already there is a lot of work done from our learning team, and they have crafted good learning paths, why not align that part to actual certification that our developers do internally for their growth conversations? And that is what was more important for us to make sure that we align it to a standard that everybody, we say, "Please follow this." And then from Enable, the next was looking at the process that we follow. Now, the Simplify is not about looking at the developer workflow in isolation, what they do in terms of development, you know, moving their code, deployment. It is holistically looking at the process end to end, and finding out all the bottlenecks. So let's start from what they do, like in the Analysis phase. We figured out what's the one of the most important feedback that a developer gave was the bad story, the quality and the acceptance criteria. We actually figured out the good way of solving for it. Now you will see some of the capabilities and when we get into the conversation of where you can see the demos of it. But that was the focus of, like how do we simplify people writing good stories and requirement? And when it came to designing part, one of the most important bottleneck that we identified was 15 days for an architecture review board to sign off a new design. We shrunk that from 15 days to five days. How did we do it? We did it through offline ARBs. How many times it happens that you have a critical project that needs to go through ARB processes and sign off and then you have to wait weeks for getting your project in for review? It happens, right? We created completely offline process and asynchronous process that developers can just log in, register and somebody will walk them through the process of giving the sign up for ARBs. And not just that, we also develop a tool set capabilities for developers to manage their Code Review process. Like in lot of cases it happens, that you are reviewing the code and completing the task in your story management systems and developers don't like to basically toggle between the system. What we did is, using Git workflows and ServiceNow integrations, we created the one ecosystem for that. So developers don't have to toggle system, complete their task within the workflow itself. And then when it come to testing, we use our own ATF to do end to end testing for whether it is functional, whether it is unit, whether it is performing testing or regression testing, documenting test cases, and doing testing automated whenever the workflow requires it to execute. That's what we actually built-in. And finally, change deployment automation. How many times it happens that we are deploying changes where only update sets are taken care of? There are a lot of manual steps somebody has to follow. It's like I have to enable a plugin, I have to upload the data. All of that manual work we completely took out of the equation. We created scripts, we created RPA bots, which can actually do that completely automated. So that is how we looked at the entire workflow and remove manual steps as many manual steps as possible. Then came the part of creating the tool set that developers would need to actually take their workflow to a next level. And this is where the new technology comes into play, the GenAI stuff. We all are GenAI or AI company nowadays. So now let's talk about some of the GenAI infusion into developer workflow that is actually yielding us more productivity gains that you might have heard in the entire day about. So in the Analysis phase, we baked into capabilities like Story Assist. So instead of product managers really focusing on nailing down the stories, imagine AI, helping them write good stories and acceptance criteria. And when it comes to let's say Development, there are a lot of capabilities like text to code, text to flow, auto complete, Code Refactor. Code Refactor is one of the amazing capability we built, where if you write a piece of code that is completely, let's say dishonoring reusability or it is completely, you know, done in a wrong way, AI can actually help you make those corrections automatically and while writing the code. So those are capability we built in. So it was not just allowing them to complete the code, it was about looking at all the best practices at the same time. We also implemented capabilities like code scan, security scan, inline scan. So imagine, you doing all those checks and balances while writing the code, not while you are deploying the code to stage your production. So all those left shift help us gain or gain productivity or reduce the rework. And then when it came to test case generation, we now have GenAI capability to generate Unit Test cases. We have capability to generate Functional Test cases, completely without let's say, you know, manual intervention. Developers just have to review and then edit if need be and then commit to ATF and run the regression accordingly. So these are the tools that we introduce in the ecosystem for developers to use and improve their productivity. And I know we did not show the demo here, because this presentation is like, 20 minutes. So we have a booth there. All of this, you can experience hands-on and you can try out every block here on the booth right there next corner. Over to you. - Thank you, Amjad, I think people are definitely enticed to know what exactly happened. So the results out there, right? If you look at it, this entire investment was about being with the developers to make them happy. And our biggest parameter, we are proud to say that our Developer Sentiment went up to 76%, which is a very, very good thing, especially on technological space out there. And as I mentioned, the side effect, the engaging community. I'm super proud. Think about the technology changes happening, I mean, the happenings, we are super sure that we can use the same community change management will be propelling further out there. Very very important aspect of it. Since we invested on learning certification, code check qualities, our code quality automatically went up, our Change failure rate went down from 6% to 1%. Pretty big achievement out there. Third, which is obviously topic of today, that's where we improved our, the productivity or reduce our cycle time by 20%, which is really big. Getting more from less was the top of the out there. And if you look at our Automated Deployment, it stands a healthy 73%, and journeys are starting. We are very sure, we are putting almost 40% improvement target for develop productivity, because of GenAI infusion development life cycle out there. So in summary, if I want to summarize what exactly was done. So we did not do it as a checkbox, we actually invested on developers wellbeing, make sure it's a movement of cultural change. So everything became as a, "Hey, this needs to happen out there." But one thing important, if you look at the important thing was about the leadership buying in. Why it is important? Because what just not this program, it required investment from developers from the bandwidth, 10%, 15% bandwidth taken away from sprints, important. We presented our data to our leadership that this is where investment need to happen. We got the buying in, go ahead. Very important step for making this program a successful. You won't see the resistance across the organization nation buying it done properly. Including HR, why it was important? Because every certificate you were taking out, it was connected to your promotion cycle, QBS cycles. It celebrated around there, people knew it as important. It was very, very taken up very well as well. Think about implementing. I think if I look back, getting everybody involved in the journey was the biggest success factor out there. We had developer champions who would connect, you know, from a developing tool to implementing team. We were so happy we did not have a single central team who could actually, "Hey, I'm developing it. Use it, implement it." The champions were involved in each and every stage. Talk about development to design, to prioritization, to testing. It was very, very helpful for us to that. Another unique thing, think about the matrix we talk about. Typically, it's considered as a management aspect. Hey, it's for management out there, but we made individual response for one number. That person was owning the definition, implementation, course correction, and kicking it out. That was very, very important for us to achieve the success out there. And last but not the least, celebrating. The investment is important, but also the individual who's taking a thing out on their hands. So apart from sending an email, we also had like a developer day similar to this, one full day across time zones, where agenda, very simple, there's a networking event, they come together, learn about new technology, share your knowledge out there. So all this coming together led us to this 20% improvement out there. So if I look at it, we did not force Enable, Simplify, Equip, on everybody's throat, we actually made it part of the journey that led us to this happiness and productive improvement. And we are continuing to invest on developer happiness. Hopefully, we learn something here, which you're gonna put into organization as well. With this, I think we are done with our today's session. We're open for any questions you may have here or additional thing as well. (audience applauding) And the mic over here in case you want some. Otherwise, we are standing. - Any questions? - Hi, my name is Anul. I would like to know more about how you have handled your manual steps. So you're talking about, you know, scripting and bars, right? I mean, this is one thing that I feel's lacking, which is like a release playbook, right? - Yes. - Because... So how do you improve that overall? Because we do have time and again where someone missed something, you know, as a manual step. - Absolutely. So as we were talking about, you know, when it comes to deployment of a change, moving code is what people normally considered like deploying. So we created, using our own, let's say orchestration platform and RP and other technologies which are available for everybody to use, we said, "Why can't we integrate that into the change process?" So for example, using RPA to actually configure an environment entirely? For example, let's say setting up an OAuth app or let's say uploading data that you require for an application to work with. All was done using orchestration and RPA together. So we created this scripted mechanism behind the scene whenever a change was deployed. So the code would go as a push, and all of these changes would orchestrate itself. The moment one event was, or like recognized, like, "Okay this task is required for me to get completed as a change task, this orchestration would trigger, go complete." And if it was successful, the change would basically recognize, "Okay, task one completed, task two completed." So the entire implementation plan, you can create the entire playbook for automation. Like these are the five steps for me to execute, deploy the code, three manual steps, previously manual step, go and execute this five bots for it, and then close the chart, task force post release validation. And by the way, when I said all of what you saw in boxes, they are there on the booth there. You can actually not just see the demo, you can actually try them hands on. (audience chattering) - Perfect. - We can take one more question. Yes. Thank you, my question will be about way of uploading changes, because you were talking about automation. Is it related to update sets or you're using source control or application repository? Which way you would recommend in order to increase the productivity? Because for those people who work with ServiceNow is say from 2008. - Yeah. - We all laugh updates sets. However, like a modern technology are saying that we need to look into the other direction. What is your experience, what you would recommend? - So, okay, I'll answer this. Should I answer? - And oh, please go ahead. - So I'll answer this question in two ways. One, as a fan boy, and one as a, you know, the technical guy. So as a fan boy, I'll always say go for the most appropriate technology for the point in time. So for example, App Repository for... When you look at ServiceNow today, App Repo is the best possible way of managing your code, source code, because it will give you the scale of multiple team working together, updates it, because still global applications are not supported by application repository. - So we in our DevOps or DevEX scale product have given flexibility for both to coexist. But as I said, the true way would be application repo, but legacy application should always be taken care using the updates at methodology. We also are working towards migrating global apps to Scope apps. Eventually, we should have zero global apps. That's our goal internally. And once we achieve that goal, we can completely go App Repo based stuff. So that's the end goal. But today, DevEX scale support both the framework equally well. App Repo gives you more flexibility and control. And teams who work with update set and the App Repository, are they coexist in the same time. So you allow your developers to decide to, or you say, "For this project, you will use update set or-" - For application types, we have pipeline types. So on DevOps, the pipeline types are defined by what kind of app it is. If it is a global app, the global app type pipeline allows them to move update sets and manage the collusions and everything the way updates set do. And for App Repo base, the pipeline structure is completely different. So we manage the types of application based upon the type of pipeline that we set up. But I would like you to basically experience it. - In the booth, so you will know how we have configured it. And if you need more technical answers, absolutely we can help you. - Thank you so much for your time. Have a good day, everyone. Thank you, bye-bye. - Thank you.