An Introduction to Studios

In this video, Our Chief Technology Officer Matt Van Vleet will reveal our roadmap for building the new LeadingAgile Studios, our newest offerings to enable clients to use their capabilities to gain the strength, Agility, and craftsmanship to take on digitally native organizations in the marketplace.

Transcript

So, I get asked a lot why a transformation company would want to have a studio? The studio gives us the opportunity to take the work our coaches are doing on site and augment that with people who can solve some of the technical problems so that the new teams don’t need to do everything in order to get the code ready to go to the next level. As we looked at why we would do a studio, it was a good thing for our clients because they could focus more on getting business value out the door and it was good for our people because our coaches could focus more on what they do, we could bring in technologists, and we’d have that one-two punch that would really help us solve the clients’ problems. Ultimately, what we wanted to do is reduce the friction of the transformation. So all of these dependencies, all the technical things that can hold us back, how do we get rid of that friction? How do we deliver more value? So if we look at the release or the product that we’re putting out to market what percent of that effort was value and what percent was overhead or waste that we could get out of the system? We talk about that as the value density of the release and if we can increase that value density then either we can spend less money to get the same amount of features out or we can spend the same amount of money and start getting more value to market and competing better in the marketplace. We need to reduce the friction that’s holding back transformations from getting to higher base camps, we need to focus on delivering more and more value to the client or from the client to their clients, we need to support and build up the teams that need to be building this over the long haul, and we need to give our coaches the ability to be more successful by being in the background and helping supply some of those major technical uplifts. So, what does a transformation studio deliver that you can’t deliver with coaching, that you can’t deliver just within the team room? We’re looking at doing four different things. One is we’re helping you do technology uplift. So if your team is focused on building features but to get to the base camp you want, you need to have an automated build or you need to have some refactoring in order to get rid of some technical dependencies and an option would be to have the studio take that code, uplift that technology, and return it where it’s refactored, has tests around it to show you how to do that, they have an automated build pipeline, or what have you. The second way people can use the studio is as a velocity uplift. So how, you may have features that you just don’t have capacity to get done and you wanna make sure that they get done in a way that doesn’t distract the transformation or doesn’t slow things down. What the the studio essentially does is it takes a backlog, it has a team that’s in the studio, and it produces working tested software. The third thing the studio is going to do is look at not just a technology uplift of the software but how do you do a technical uplift for the team? So if there’s a team that needs to learn a new set of practices, something usually in the area of the engineering practices, many of the management practices we can teach just by coaching but the engineering practices may change how you write every line of code, may change what you do on a daily basis, not a monthly or a weekly basis. So there’s some fundamental things that a team needs to learn how to do. They need to get the muscle memory of how to do it within their code base. So in those situations we’ll put the team through a dojo where they can go learn these practices on their code in a controlled environment and then all of those three things go hand in hand with coaching because if we change how the software is built, if we change how you test the software but we don’t coach and work with the team to get that into their daily practices then over time you’ll have atrophy and what we just spent money on and invested in is not gonna sustain and be of high quality. First, let’s start with how transformations work. We have our base camp model. So different capabilities or different products need to get to different base camps. So those different base camps have different goals that we’re trying to achieve. The way we figure out what base camps, which components or which applications need to go to is we have a process called defining the end state. Defining the end state defines where do we wanna go, what’s the vision, and how do we make sure that we know which applications need to go to what level? Define the end state sounds like it might be a one-time process but we re-envision that end state every quarter. So we’re constantly looking at where are these capabilities, where are these products, and then where do they need to go? So, during a define the end state, for the applications that need to go to base camps three, four, and five which have a high technical dependency, we then do a technical uplift assessment to understand what’s necessary in order to get the technology and the teams to be able to perform and to be able to deliver at those higher base camps? So there’s a whole set of things to do from a structure and governance perspective to make that happen but there’s also typically something to do at the code level where the code is dependent and not designed to be built in individual components or modules without being highly coordinated across the different releases. Ultimately we are gonna have an outcome where we want to release more often and increase our value density not decrease it. So that if we look at that measurement of value density we can then look at what technical practices are gonna help us keep that value density high? So the way this will role out within LeadingAgile and within our clients’ expeditions is that in the define the end state we will dine the goals, understand the constraints from a technology perspective, but not flip and make technology enablement the goal. The goals remain the same and the outcomes, and we will use those technical practices to help achieve the outcomes of those releases. Now let’s talk about who is involved in the studio. So first of all, as we’re doing a transformation studio I’ve talked about there being this kind of this one-two punch, right? We have technical coaches who come along with our other consultants and are part of an expedition team and help move things to the next level. They have access to talent within a studio, which is a cross-functional, fully capable team. So it will have the leadership it needs to run the team, it will have the engineers, it will have the digital experience people and quality people, whatever is needed in order to produce that working tested software. When we’re looking at studios and we’re talking about the why and they what and the how the who, it’s important to just understand how that fits into the overall journey, right? Clients have a set of capabilities, they have a set of systems, they have a culture, they have an environment and we’re working to align those systems and structures to the clients and markets, right? So as we help get those things aligned there’s a journey that needs to happen to get through these different base camps. Where studios fits in is that we’re working to work with the teams on the ground to help make that journey a more smooth journey, either because we’ve been down that path before and we can help you get there faster or we’re just there to help lighten the load as we’re going along that journey. In the end, we need to stay focused on how do we get more value out the door, how do we get organizations to be able to perform at the level their products and their clients need and studios is an accelerator that helps you get there.