Hello, everyone. Uh Welcome you all to uh my session on uh Leading DeVos Transformation. I'm very excited to uh discuss with you uh on uh uh DeVos Transformation and uh some details about me uh myself, Archana Nasar.I have been working in uh software development and delivery for 20 plus years. I have been leading different uh uh technologies uh working in different domains and uh introducing new technologies to clients, working for different uh fortune 500 companies. And in my last role as director it, I have been working uh on Devops Transformation uh implementing uh and strategizing it for a business unit. And so I'm excited to discuss today with you all on Devops Transformation and let's get started. So here is the uh brief agenda uh on the DeVos Transformation. Uh So we will see what is Dews uh and why develops some barriers and then finally leading to Dews transformation. So let's get started. I would like to uh start my presentation uh with uh this Dews Industry research report uh which uh talks of uh how the organizations are uh able to uh the top performers, the elite performers, how they are able to perform and how they are able to do frequent deployments and with stability, uh they are able to reduce the time of the incident in production and the changes they are able to stabilize it in production.

So with this thought and the report, this is from Devops industrial reports. And it also suggests that how organizations can uh the organizations can uh follow these uh leaders and in terms of having the right culture, uh having the scalable systems and uh start with the devotion.

So let's get started. Uh So, uh how is, what is Devops? Uh So, Devops is uh uh devops is uh if you see the traditional development, uh we have the business uh teams, we have the development teams, we have the testing teams and we have deployment teams and everybody are doing fantastic in the areas, have a different set of priorities and focus.

But the challenges are the differences, we start to see when there is uh we start to uh handshake and uh move the work products around these different teams. So Devops is trying to address the uh better collaboration and having everybody together. So uh if we see as Devo stands for development and operations together, so let us uh see that how the development is having different uh focus. So they have the developers, they will have focus on having latest technology, getting features out quickly and with quality delivery and getting less while the operations will have uh the focus on how to deploy this in production, how it should be uh uh stable in production and how it should have minimal impact to users.

So, dev ops addresses this, having getting both development and operations team together and uh uh how they can work together and uh uh move forward uh with the journey of uh quality software de delivery. So if you see the definition here, uh devops is empowering uh delivery teams by removing inefficiencies across software life cycle. So the I've highlighted software life cycle as it empowers delivery teams and removes efficiencies throughout the software delivery, right? And we will see uh further de details.

So what is DeVos? It is cultural and organizational change. Uh It is simplifying your uh different processes, software development and business processes. It is eliminating waste, it is uh tools and automation throughout the journey and it is collaboration to move forward uh successfully together, right?

So, uh uh now why there s we might have come across when we do software delivery and development that there is uh teams working in silos, there is uh uh late uh development, uh slower testing, a lot of defects and the bill doesn't work in production, right? So Devops tries to address this end to end and tries to make this entire process faster, better and cheaper, right? So you, you might uh come across like I'm doing already agile and I'm doing iterative development and I'm ex exist. I am already accepting changes as they come across as I come across in delivery. But to just to highlight here g addresses the change in requirements from business to development and devops uh and it stops their development, right when the product is ready, but devops goes a step further and it addresses how it delivered or how a ready product can be delivered to production and to customers quickly.

So it addresses the gap between development and operations, right? So here is uh some comparison like agile business and development. Devops related to development and operations. It is a agile addresses, working software. Devops addresses working software delivered successfully.

Then agile addresses processes around building automation and devops has uh its own set of uh process and practices. What we call is continuous integration and delivery. Uh where you the as the uh developer checks in the core, it gets continuously integrated and tested and the testing to test it uh in other different phases like UIT and so on then configuration management and the infrastructure which is, which used to be traditionally as a manual process where you do the uh provisioning uh manually that can be addressed through code, change, coding and then virtualization and containerization and continuous monitoring and production.

So, Devops takes care of end to end software delivery uh enabling different processes and people as we move from this journey, right? And so G letter says how to develop software predominantly focusing on development part of it. While the the work focus on end to end responsibility and some of the business benefits of being it being the uh addressing across the software development life cycle. It has benefits across business. Uh better ro i frequent releases uh predictable delivery than across organizations where it is empowering teams, uh cross pollination of skill and then variety better code quality, traceability, better automation and processes and better deployments, lesser defects. So this addresses across um all the uh software um uh entire uh business operations and uh it de benefits for all. So now here, uh let us spend some time on barriers to develops uh as we move from build to test, to deploy, you might see that there is a challenge in having the handshake the month, the requirements are done and how they move to uh development and then from developmental testing and then to deploy, right?

So uh the there can be uh certain things which can uh hinder this progress and which are already been there as a legacy and we do so these things which uh can, which uh which might be seen as a barrier, focus on them and try to address them early. So let us start with the barriers here, the inadequate leadership support. So here leadership support is not only in terms of budgeting, it is also in terms of as it develops changes. Um It may be overwhelming at times and a lot of uh change for individuals as well as across organization. So leadership support is very critical as people might have some resistance or to change or they might have certain ways of doing things and they may not be very open. So to remove those uh differences and get a leadership support is very, very critical throughout the entire journey.

Then organization culture, how sir is it supporting innovation? Is it supporting new thought process? Is it supporting risk taking behavior or are we shooting the messenger? So the organization culture has to be uh innovative and supporting uh as a lot of changes are going to be introduced as part of the devops journey. Now analysis paralysis. It is not so uncommon uh as it addresses the process, people, technology and tools and automation, everything to do with the software development. Once you start on this journey, you might feel where to start a lot of things to change, but you can step back and uh start take your time, do some analysis but it should not be like we are going into uh never ending cycles of analysis, right? So that analysis paralysis should be cautious of then no a no or a inadequate tools, automation. There may be some organizations may have some tools they are already there and they are socialized, those tools but some may not have and they may be just starting to think of automation. Some are already doing continuous integration but to do delivery.

So this kind of different stages, organizations might be some are just doing waterfall, they are not doing a Gile and waterfall. So these tools, automation might be is it by barrier and we need to be aware of then inconsistent and heavy processes as it is, especially with the large organizations and enterprises where the software has been delivered for years and years together, we might come across processes and have uh inconsistency in them.

When organ one department uh uh follow certain way of doing things, the department follows certain way of doing things. So how uh uh everybody and processes together, how do we start? That can be another barrier to start with then scarcity of skills. Uh not everybody is uh having uh digital skills, how to automate things, unit test, assess testing first and uh uh different tools new and with the it uh a lot of new tools are getting introduced, the Devops journey, getting everything automated. So that can be another reason then software delivery by vendors that can be another challenge. The regulatory compliance, you are into very highly regulated environment, you need to be cognizant of that and then the legacy applications. So these are some of the barriers which uh you can be uh aware of and can get uh uh when you start planning the journey, you can be uh keeping these things in mind and get starting. No uh uh uh uh transformation uh demystifying. So it is uh it's not another silo but cross functional knobs works together, work together and get uh uh on the responsibility and deliverables, right. So it's a cross functional team working there, business Q A and operations working together for a common goal. Does it one size fits all? Not really, there can be different things with different organizations and different business businesses.

It can be team size, it can be a very small team, it just uh uh 20 people team or it can be a large organization, 100,000 people can be a different domain. It can be straightforward. Do it can be a very complex domain where a lot of regulations and all, then you have geographically distributed teams, a single location, uh different locations across the globe. Then your organization, is it like having outsourcing heavy on outsourcing? Is it all uh in hosting or vendors are there? So that can be another differentiator and then technical complexity. So what kind of technology is it? Uh uh how many tiers multi tre application is it a uh client server application? Is it a desktop application and your compliances uh regulatory as well as other uh compliances, your industry demands? So all these things are different for different organizations and businesses. So it will not be a one size fit all solution. You will have to an understanding of your way of working your environment and then go for the journey Now, these are the some of the things when devops is in operation. So with the devops, you have agile and automated teams, cross functional teams, everybody collaborating, uh various multiple releases in a week or a day.

You can decide the frequency as it suits your business and constant collaboration, quicker turnarounds on your defects as well as features, constant feedback, uh constant learning and uh overlapping responsibilities and power teams and automatic testing and fail fast. So, failure is uh uh very well like support, supported in the sense, you can take chances and learn from that and move forward in implementing different technologies, right? And now uh leading the s uh transformation. So as we saw, it is uh uh kind of getting development operations quality and of uh entire delivery together. So it is the journey from no des to des. It is it starts with observe, plan and act and it goes into that repeat cycle, right? So you can uh have different uh uh ways of uh working. Uh You have different uh technologies, you have different team uh structures. So you need to uh understand first observe what are the things and then how you can go for your journey. And so it is uh definitely it's a journey and it's not a destination. So it cannot be like I'm done with them. You have to keep, it is a continuous improvement process. So you keep on doing different things and keep on doing enhancements and bit by bit, you will move closer to the works. But the moment you come there, you will see, OK, I need to improve, this has become heavy for me now or this tool is not working.

So I need to change this. So it's keep on like optimizing your way uh your work and operations. Now. Uh what kind of leadership which can help in this entire journey? So the leader or, or the uh uh person who is giving uh who is helping and facilitating this entire journey should have a clear vision why he is doing this. Then the supportive leadership support uh to the teams as well as to the uh the uh direct responsibility who is running all this uh to support to the entire team, then the intellectual stimulation uh getting people to work and learn faster and quickly uh apply those concepts, then inspiring them uh with uh personal recognition and uh getting them all together uh and encouraging on the uh this journey, right?

So can be achieved using transformational leadership to enable organization wide changes as it is changing. And it may be like at times, it might look very uh not so uh easy to do, but with the right leadership support, it can be achieved and it we can start with this journey. So now uh how do we start? So uh as we discussed, it is not one size fits all approach. So identify the pain points and it may be different, different pain points for different organizations. Some uh some might have very heavy on processes, some might have zero tool uh implementation and uh uh some might have very cumbersome architecture. So you need to identify what is, what are your pain points and which you need to start addressing first in when you start with the WES transformation, right? Then the second would be um how you uh get on to uh your um uh what is the, define the scope, then define shared responsibility. Uh What are the shared goals? And how do we reach there? Then define process bottlenecks.

What are the process bottlenecks which are coming across? Then what are the tools which we need to use? What we are targeting? Are we targeting continuous delivery, continuous integration and tire or in pieces so that we need to define and then identify the right project and metrics to start with and lead time for success. It will not be immediately you will be able to see the success. So you need to give some time to get uh uh success in this. Then the recommendations uh engage an expert, continue support to teams loosely coupled architecture, uh define your measurements and milestones and continuous learning and feedback. So once you start uh doing this journey, you will have to have a devops team and you can have this um uh supportive uh loosely coupled architecture. So you can have scalability, maintainability. Define your measurements. What are your metrics for your devops success? What are your milestones and have the continuous learning and field by going? So that's all uh I have.