 So welcome to this session, dojo session taking agile and DevOps to the next seven by Jeffson, D'Souza, and Vijay Thakri. We are glad they can join us today. So without further delay, over to you, Jeffson and Vijay. Hi, hello everyone, myself Vijay Thakri and I'm the DevOps practice lead in Accenture and I have Jeffson on the call. He's the Goron agile practice lead in Accenture and also he leads the whole living systems in Accenture. Jeff, if you can move on to the next slide. OK, the today's topic about is the whole dojo ways of working. Why this paradigm shift is required in agile and DevOps. If you look at the whole industry report, as you know, that agile and DevOps is there for last many years. And if you look at the latest industry report, both for agile and DevOps, if you see that there is the adoption is there across everywhere. And but if you look at the whole maturity of this adoption, right, which is in case of in agile, it is almost like 16% today. And DevOps have taken that report from the recent Dora report, where the whole allied performance has increased from 20 to 26%. So but there is a long way, long there is a big gap. And a lot of organization has to catch up on this. And but to there is a if you look at that, there is a big gap is there who are like still at the lower maturity or they are at the medium or at the higher level of maturity. So it is very important for every organization for them to move to the next level to get the more say, for example, if it is they want to achieve like for 360 degree value from this agile and DevOps, there is a lot of things need to be done in the coming days. So the focus should be there on one is on building this whole capability in the full stack engineering that is building this full stack atomic feature teams. And also there is an continuous focus should be there on continuous learning and innovation. And the next is on the cloud. So it is continued to be a differentiator and it will be continued there for many more years. And finally, the focus should be there on the whole resiliency. How we can build this whole site reliability engineering team to make sure that we provide this 100% of time for all the applications what we deliver. So how can we do this like how can we achieve this the whole paradigm shift, right? What I'm talking about for both agile and DevOps. So let me give you a quick example of how we are doing what we know about DevOps today. So what is the perception there in the market today? Like, you know about DevOps, the perception there with the DevOps today is everybody knows about DevOps by continuous integration, continuous delivery, continuous monitoring and the whole automated infrastructure that is the infrastructure as a code. That is what we know today about DevOps. But if you look at the way it is evolved from last couple of years, the focus has moved from the traditional CI for custom because move to focus. Now the focus is more on the cloud, DevSecOps, the data science, machine learning, AI and all about this new ways of working. There are new tools in the market and the whole platform what we talk about for the DevOps is gaining a lot of momentum. And we talk about many tools in the past for the CI CD pipeline. Today what you see here is that entire thing is now provided by one single tool like the GitHub, GitHub or the GitHub and even for the cloud based Jenkins or even in the discussion happening in the tooling also, that is the traditional way of like where the engineer should know about only Jira, Jenkins, Confluence or Maven. But today it is something which is they should know everything like along with that, they should know Docker, Kubernetes, IAC and monitoring tools and even a lot of this event based architecture or the Prometheus, there are many things actually. And as I told you about, it has to be more for building it is very important to build this full stack capabilities and also the whole ways of working also has changed like traditional like more of a reactive support to more into the site reliability engineering, the save and also bringing this whole lean governance. Before moving on to the next slide, why I'm telling about all these things, right? Because today now the most of our customers are today moving from their the complexity of complexity have changed and also if you look at with the coming with the pandemic also, the whole ways of working has changed. So let me give an example, how we have addressed one of these challenges for one of the large telecom client in North America, where this is for the e-commerce platform at any point of time, they had like more than 25,000 users on the e-commerce platform. So if you look at the whole landscape, they had like thousands of releases they are doing on weekly basis and everything either they have this entire infrastructure or some of them are on their own premises, some of them are on cloud and the complexity like they have to do this hundreds and thousands of releases. So the thing is one of the challenge which they have faced here is the skill to deliver these changes on demand release basis. So one of the things which we have addressed here is through the what we have brought in here is the whole dojo concept, right? You know about the whole dojo. So it is more about this immersive learning. So what we have done is we have brought in this whole dojo based learning experience for the entire team here to deliver faster and with the predictable releases. So this is something we have achieved through because the complication complexity and also the whole infrastructure complexity and the skill required for many of their engineers like bringing in this whole full stack feature teams. So it is very important for them to take them through some of this immersive learning experience so that to immersive learning experience based on this whole hyper sprint because we talk about this whole hyper sprint based learning where along with their delivery they used to spend like at least the two and a half hours every day based on their use cases which is very much related to their project. So we talk about that how we have achieved and based on this experience, what we have done here is like we created this, okay, when we started thinking about how we can scale this, how we can industrialize this, right? And how can we try this for across all the project? So for example, when I'm talking about developing any application rather than doing this more of a feature based, how can I split this vertically and bringing this whole hyper sprint based delivery, right? And delivering this everything through this minimum viable product, right? So next I will hand it over to Jeff. We'll talk about how we have achieved this, how we have industrialized this and how we are going to address this like more of this full stack engineering feature teams from the traditional I-shaped or T-shaped scheme to the E-shaped scheme for future. Thanks, Svejan. So as we talked about that, you know, we really wanted to really address some of the challenges that our telco customers are facing. And that's where our first experiment was applying a dojo approach. It said, okay, we start with, you know, dojo is all about let's do hyperspins, let's have two spins in a week, right? Let's go with the dojo for what four weeks. And this is where we started within the expectation is that end of every spin which is two and a half days in a week, we'll have a spin demo, right? And then we'll have the MVP. We just talk to the team and say, okay, this is what we're going to try, right? Just to address some of the challenges they had in terms of learning, in terms of agility, in terms of, you know, busting some of those impediments ahead. Now, having said that, what did we learn? And to be honest, from our first experience itself, we failed and it was quite obvious that we failed. And in some of the retrospective sessions when we spoke to the team, one of the things is the team felt burnt out, right? Because delivering working software in every two and a half days is absolutely not more strenuous than compared to the experience. The product owners, they were not happy that every spin, the team would definitely not be able to deliver what they really want, right? The learning from the team. Dojo is meant to be immersive experience. The learning went for a toss. They're all focused on delivering what they spent was all about, right? The fourth important learning was with the team sense, right? You know, within our days of collaboration with a large team couldn't really work out, right? So those were some of the key learnings we had, which is where our first experiment, while some people call it success, I would, as a coach, I would probably say, it's probably not there, right, or maybe fail, right? So what do you do? There definitely had to be things which we had to do to make it work. And we came up and we kind of modified this whole dojo approach as a three hour approach. We said, there are fundamental things you need to do differently. And, you know, we call this as, the first thing was about the realign scope, right? This is where we first said, it's not that dojo, within the dojo framework, you have to deliver two weeks' experience into our database. It's not that, right? We had to look at how do I really size the stories well so that the stories can be delivered is as many ways in a vertical possible, right? And that's where stories were then size and shaped up based on sad scenarios, happy scenarios, or exception scenarios, quality scenarios, constrained scenarios. Those were the different scenarios where each of these user stories was then further split up. And those scenarios that were then assigned to the base on the priority, base on the business priority, based on the technical dependencies, they were then assigned to those sprints. So that's one big change we did. And as a part of that change, what we also did is we kind of strengthened the squad in visiting areas as well, because initially when we went into dojo, we said, okay, we have the stories in place, let's move on instead, let's start with implementing dojo, right? But we said, okay, now with this, because of the whole scope issue, can we rethink about how we structure the whole squad and visiting area, right? Where we have the right people in it, we have the right tools in it, we have the right capabilities in it to really think about splitting the stories up. So, and also the process as well, just to make sure that at any given point of time, we have a good amount of stories who are, which are refined well, and which fit into those small, and the other focus also was on the MVP, right? So every two and a half, every four weeks, rather than thinking that every sprint will deliver some MVP, right? We felt that, okay, how iterative and incrementally it can be there. And that's what at the end of every sprint, I'm sorry, at the end of every dojo, which is about four weeks, what is the MVP we are looking at, right? So that's why the whole focus went around, a lot of changes as a part of the whole envisioning process and also the way we defined our granular stories, if I will. The second part, an important part was about the realignment of the team. Earlier, we had about 12 people in a team, right? So that's where 12 people was definitely a lot more than what we could take, right? And we said, okay, we need to have sports, right? And that's where we went with five or less, five was the max. Ideally, we said about three or four people working in one team, but they said five is max because some teams and I said, if we can't move three, we really have to deliver something. And to end, we need really five people. So I said, okay, for the time being, let's start with five people, right? So that's why we had smaller squads along with it. We also then re-purposed some of the processes as well, within the, you know, within the spins as well. So we kind of kept it fluid for each of the teams to say, okay, when they want to do standouts, when they want to do a spin demo, when they want to do a retrospective, right? Some of these things and how they want to conduct it as well. At the end of the day, it's all about agility, right? So that's the second part. The third part and a very important part, you know, was about the thinking itself, right? And that's where dojo is not just about hyperspeed, right? It's about immersive learning. It's about, you know, busting your impediments much faster, right? And that's where what we said is we kind of get that learning behavior within the team. Initially, we started saying, as a part of your spin backlog, 10% of your time is going to be spent on learning. And in some teams, we also saw 15% of their time on the sprint time was mentored learning. End of the sprint, in the sprint demo, while the functional demo was going on, right? They would also demo what they have learned as a part of the sprint. And this was aligned to their product backlog as well, right, in terms of what is the learning required for the future to really build the future part of the backlog, right? So all this all kind of got into thinking where not just the team, but also the business also got involved in this thinking and in a reshaping of the way the teams really work, right? So those are the fundamental things which you really have to bring it to really make the dojo thing more experiential and make really work, right? Now, having said that, to what we just said, right? Today, you know, in the whole digital world, talking about, you know, full stack engineering, talking about skills, right? E-shaped skills. And that's where one of the aft of this team and unsuccess factors of this team that they were able to move from a T-shaped skills to E-shaped skills, right? There is a power of T-shaped. You're looking at large, I mean, looking at siloed functional skills, right? And, you know, siloed technology skills, right? That's where we kind of broadened it out, making sure that they have broad functional skills, right? From understanding the business domain, understanding different stakeholders, understanding the value stream mapping, right? Making sure that, you know, you understand what's value-adding, what's not value-adding from a customer standpoint, bring that customer-centricity as a part of thinking, right? Those are some of the broad skills. And then from an engineering standpoint, this particular engagement was basically on cloud, right? And that's where this whole particular team, and that's where learning about the cloud-related services, learning about the whole tooling aspect, the software engineering and learning about, learning and building about the automation piece was also core part of this team, right? And that's where, when we talked about that, you know, today it's not just about, you know, siloed teams, right? It's not just about the team members. It's also about end-to-end from full-stack team engineers. And it's important. And why I say it's important is when you talk about, and I'm going back, right, when you talk about spot-to-spots, you're probably looking at teams which are really are able to do multiple of these things as we started, right? So that's why, initially, this particular team did start with a lot more siloed teams, right? But the end goal was to reach, you know, B-shaped skills so that really helps the whole movement around Dojo, you know, more successful. Now, having said that, doing all this after a couple of Dojos, right? I'm really looking at what did the team achieve? Yeah, for me, honestly, this particular team, it was more about, you know, from being agile to being agile, right? Being agile, yes, absolutely. They were running those scum teams. They're running the two, three-week streams, right? But really, were they being agile? Probably not, right? And that's where the Dojo, you know, ways of working really made that fundamental cultural change, not just within the team, but also from a business standpoint as well, right? And these are some of the outcomes, you know, you'd see, but I mean, honestly, these are, for me, honestly, these outcomes are more, you know, it had to happen, right? That's what I say, right? If you're being agile, you definitely have a high velocity compatibility. You definitely, you know, have ability to, predictability, you know, right? Your CSATs goes a little bit down. You are able to deliver what the business really wants, right, in terms of business KPI, all your, the work that you do, you know, will be aligned to, okay, how am I helping the business have better revenue or have better, you know, customer experience or reduce their cycle times and all those aspects are kind of covered as a part of the, you know, outcomes for this particular team. Now, while this is, you might think, you know, hey, this is great, but, you know, can this really be scaled up? Now, based on our past experiences of working with Dojo, with the teams, we kind of looked at, it's a scalable model. It's not that it's a, you know, a model which is just a map to us, particular team or a particular, you know, engagement. This is a scalable model, and that's why if you look at it, we are seeing this as in delivery, Dojo delivery, and this is where not just leveraging scrum, but also now looking at scaling that as a part of your scale frameworks like Save or less or some of these frameworks, right? We're also seeing, we're surprised when some of the delivery teams came back saying that they've applied Dojo as a part, Dojo Concepts as a part of learning, making sure that, you know, they are working from T-shaped to E-shaped, right? They've also applied Dojo in some problem-solving areas, right, they had a big problem and they really wanted to solve Dojo. So we kind of applied the Dojo Concept as a part of, you know, solving, now problem solving. The one which really surprised me was the automation piece, right? And because the reason why it surprised me is a lot of complexities around automation, talk about how AI based automation and all that stuff, right? And that's where I've got a couple of teams which have actually implemented Dojo in really applying, you know, A building those assets and then, you know, and then deploying those assets, right? So all in all, I think it's not just according to me, Dojo is here to stay, right? And just making sure that, you know, it is not just, you know, for a particular team but can be expanded across the various teams and across the various work groups, right? And just to sum it up, Dojo is not about, while a lot of people when they think about Dojo and they read about Dojo, they think it's all about two and a half days of hyperspins, hyperspins, right? But according to me, Dojo is all about a framework which will help you to discover those impermanence which are hampering your productivity, hampering your efficiencies and then busting them at hyperspins, right? Making that visible for everybody, those impermanence and helping teams to from being agile to being agile. With that, I'll pause here and see if there are any questions for the fund audience. Thanks again, Jess and Vijay. That was a wonderful learning experience and, you know, good to know about your experiences. I am sure everybody will take greater value from this. Thank you. Thanks, Devish, for having us here. Thanks, audience. Thank you. Thanks, everybody. Thank you. Thanks a lot, folks.