Andreas Prins

Hey, good morning, good afternoon. Welcome to this presentation. My name is Andreas Prins. I'm working for Digital.ai, and today I actually want to guide you through a story that goes beyond the first steps in the digital transformation.

With so much automation at our fingertips, how do we scale beyond the first week, beyond the first month, and beyond the first year? And that is where we want to talk about today. We all know that setting the first steps in the journey is not so difficult, but truly understanding where you want to go in the long term, while everyone is already a few years into digital transformation, I want to help you out with a lot of real-life examples and instruments that you can use tomorrow to move forward.

So how do we design for scale? Ultimately, we want to end up with four tips that get you started, that you can use and apply beyond your first year, because in the first year you will face difficulties and particular struggles, but your journey needs to continue also after this.

Before we go into the journey, I do want to share some really, really nice news. Today we're launching the fourth version of the periodic table. At this point in time, I can imagine you're all familiar with this periodic table, but we're really excited to launch a new version with new segments, with new tools. Also some tools left the periodic table because there's so much going on in the space of automation. New areas of automation occur. In particular, in the cloud and container space, we see rapid development, but also in the other segments, there are new tools coming up. If you want to have a copy of this, please go to our booth and use it, get a download of it, and start using it. As soon as there's a physical conference again, you will absolutely get a real copy of it that you can use.

With all the automation out there, and all of us being familiar at least with a few of them, the question sometimes coming to my mind is: how do I plan in a really structured way the agile journey? That is what I want to talk about in the first place. With so much automation out there, how do you plan and how do you know where you need to go?

I want to guide you through three instruments that you can start using tomorrow when you come together digitally or physically. The purpose here is really to start tracking and measuring what matters to your organization.

The first one that I want to share with you is an explorer map. I've used it myself, so I'm talking here from real experience. It has nothing to do yet with CI/CD or with any automation capabilities. The explorer map is a powerful instrument to understand where you want to go in the longer term: what is your goal, what is it that you want to achieve, and then start articulating smaller sub-goals derived from it. Ultimately, to achieve a goal, you need to articulate actions. What is it that I want to do to achieve my next goal? Then you start planning actions again to go towards your next goal and ultimately achieving your big goal.

What I've learned from my own experience is that we can talk about the digital transformation and that we can start doing a lot of improvements, but if it's not clearly headed into one direction, you will notice that you as a team, management team, leadership team, or DevOps team, are a little clueless. You don't know exactly what you want to achieve.

Coming together as a team, again, development team, management team, or leadership team for a day or two, really thinking through what is it that I want to achieve, putting the many goals on the wall, and then starting to plan a journey of steps towards a goal is a really powerful instrument to start understanding each other.

I've learned from my own experience, having the ability or the need to guide a team of 100, 200, or 300 engineers, operations and development engineers, into that digital journey, it is important for you as a management team that you come together and have the conversation about what it is that I do want to achieve. By doing so, you will come up with drawings that you can put on the wall a little later in time. This is helpful because now all of a sudden, all of you will have a common understanding of what it is that you want to achieve. I can recommend starting to look into it, and the source materials are available for you to use.

The second instrument I want to share, also based on my own experience, is what is called the Obeya room, or the visual room, where all the data is coming together. In this Obeya room, you as a team, a management team, a leadership team, a DevOps team, or just a business-line team, can come together on a daily and weekly basis to understand where you are and take actions and mitigations to go towards your goal.

An Obeya is an instrument originating in lean practices. What you will see in this Obeya is, at the top left, the long-term plan. You can use explorer maps, as I've just discussed, to manage the long-term plan. Then all the actions that you need to take on a daily basis, you put them on the week board. If you're not a development team, you will notice that you will see a lot of managerial tasks on this board.

This is important, I believe, to be there on a daily basis, because if you believe that a transformation of all your teams only happens through continuous effort, you as a management team or leadership team need to be out there to manage impediments, solve problems, and take actions to help your teams go forward.

At the top right are the impediments: what are the blockers? This is not just budgeting or risk. This can also be in teams, if there is a bad team spirit or atmosphere that you need to solve, or it can be in the application architecture. You can have the desire to innovate, but if there are impediments from a technical perspective, that can hold you back. The Obeya room is a really powerful instrument to manage day-to-day activities in alignment with the long-term plan.

At the bottom, you will see a lot of charts and measurements coming in. You need to discover what are the metrics that matter to your organization, that truly measure progress, quality, and change. From organization to organization, I've learned from all of our customers, this truly depends on who you are, what you want to achieve, and where you are in your journey. But thinking about what are the metrics that express whether I'm progressing towards my goal is really important.

Last but not least, at the left side, you can put on the board what are the successes and the failures. Going through a digital transformation is also a continuous learning journey, where you share the successes that you've achieved and the failures. With doing so, you will get a learning organization, which I believe is foundational to manage an organization at scale through the journey.

We've seen how we can go from big goals, next goals, and actions towards a visual room to manage it. By the way, you can perfectly do this in a digital way with all the collaboration tools that are out there.

The last layer is now go to the teams. What can they use to manage their digital transformation? Personally, I do believe managing it from a visual board, whether or not it's physical, 12 weeks ago when we were still in the office, or digitally when we're all working remote, thinking about three elements for every DevOps team is important to improve during digital transformation.

The first one is all about future work: what is it that we want to achieve? That is why planning the future work and the direction at the higher level is so important, because we need to align these two together. It cannot happen that we express goals at an enterprise level or a business-line level that are not aligned with the underlying teams that do the execution of the work.

In the middle, you need to manage your current activities and truly think about how to visualize it, because having a clear visualization of the change that you want to make and the issues that occur in the field is important. What I've learned by putting both the change, the new development, on the same board as your incidents and impediments, is that this helps you to improve. Why? Because by having the incidents visible on your board, it hurts. It's funny, but it hurts.

What you want to do is lower the bar. By lowering the bar, you're doing two things. The first thing that you're doing is making the space for incidents smaller and smaller. By doing so, you need to focus on improvement. The beautiful side effect is that you're freeing up more and more time and capacity to focus on new change and new additions and capabilities for your end users. That is why understanding this in relation is important.

Last but not least, the historic data. It is important to maintain data, to keep data, and to learn also at the team level from what has happened. I promise you, start with the basic ones that you all know and that we all use. But then in retrospectives and in other conversations, learn what really matters to you and to drive your improvement. What is the historic data that shows you the insights on how to move forward? Then we have a feedback loop, because the data from the past is helping us to make decisions for the future. That is important in the digital transformation.

You were probably expecting some concrete examples on, "Hey, I did this and I did this," and another activity. What I've learned is setting up the infrastructure and almost the ecosystem to manage change is equally, or probably even more, important than just focusing on the automation of steps and activities. I do hope this first section has given you a really good insight on how to do that at a strategic level, a tactical level, as well as at an operational level within the teams.

The next question that we see happening in our customers, and I recently had a really good conversation with one of our customers in the UK, is: how do I design for scale? Starting the journey, discovering the first steps, is pretty easy. It's just all about automation and we improve a few steps. But then the question is, how do I roll out practices to all my teams? On one hand, rolling out practices is good, but at the same time, I do want to give some freedom to my teams to operate within.

What we see happening at many of our customers, and in particular large customers having thousands of engineers involved in that entire DevOps transformation or cloud and container transformation, is that they start thinking about DevOps as a service. By saying DevOps as a service, they are articulating a fine balance between, on one hand, standardization and, at the same time, freedom for engineers and engineering teams to move forward and make their own decisions.

What we believe and what we see at our customers is that customers who articulate a good balance, saying, "Hey, these are the main blocks that I do want to see in your pipelines. But how you do it, with what tools you do it, that's up to you," have a really good balance between the two of them.

An example here from one of our customers is articulating at a higher level the five phases where pipelines need to go through, or where a delivery needs to go through, to be precise. It needs to see something on the planning side. Whether that is Jira, or whether that is another tool or your change request, that doesn't matter that much. It's all about planning the change. Teams have the ability to, in whatever way, link their epics, their stories, and their change requests all together.

Then there's the entire build, the test, the deployment, and the pre- or post-deployment to production. In each of them, you can imagine performance testing and security testing are two mandatory activities. That's a given. You need to show or come back with the results in the entire pipeline. But what tools you choose to do performance testing or security testing, that doesn't matter that much.

I'm a big fan, and I do believe that having this fine-grained balance of saying, "Hey, I do have these five phases, and in this I need to see outputs," is a useful way to measure it. DevOps as a service, coming up with standard services that are ready to use and available to all teams, can be a really good way to do so. Having predefined patterns is something to provide the knowledge of the experts to all the teams. At the same time, by articulating it at a meta level, you can get the data back that is important for your auditing or for other reporting purposes. That is a good way to scale beyond the first few steps that you've made.

Another way you can start thinking is: how do I position security and governance in these standardized pipelines? Beyond saying, "Hey, I just have these five phases," we also see many organizations saying, "For security and performance or compliance, I do have standard building blocks that every team simply needs to go through." Depending on your development, on the type of artifact that's coming out, you go through a pipeline that includes Checkmarx or Sonar scanning and these kinds of capabilities.

Having these standardized building blocks helps you bake security into your pipeline. By doing so, you get two things. The first thing is it's not an afterthought that you say, "Oh yeah, before I go to production, I do need to do security and performance." No, it's there. It's in the standard process. The second thing, what I do believe, is if you want to scale beyond the first steps, you need to have all this auditing and compliance baked in. It's helping you to renew and review all the rules and checks and balances that you've put together in your risk framework. Thinking about this upfront helps you to accelerate, and it is important if you are in your journey for a little while.

The last one here, I told about it already, is enforce the required and leave the space for the optional. It is important to understand how to scale from one expert to all of them in your organization. I also believe that organizations need to think about this upfront. If I have particular practices, can I share this as code using GitOps practices to my entire organization? If I'm onboarding on the cloud journey, I cannot make every engineer a Kubernetes expert. So how can I use his knowledge through standard building blocks, through blueprints, through as-code practices, to scale this out to many, many DevOps teams that are out there?

A little while ago, I had a really good conversation with someone leading engineering teams in BT, and he told me this is important because in particular these experts are often external consultants coming in for a few months and then leaving. How do you leverage or actually gain his knowledge and put it into blueprints and then share it through the tools that you have out there? Thinking about this upfront, I believe, is important in your digital journey to accelerate.

We've seen how to plan a journey and how to think about scalability and standardization. I do want to finish up with four tips that you can utilize beyond the first year. Again, they're probably not the most obvious ones, but I do believe thinking about this is important to accelerate and ultimately to make the next step in your digital transformation.

The first one will be about extending your view post-deployment. The second is to discuss the success of an initiative with your business partner. The third one will be about taking the bottlenecks that you will all have in your process very seriously. Last but not least, going back to where we started, how can you use explorer maps to start planning your journey in a better way? Let's take a look at all four of them.

The first one, what I've learned while I was managing my DevOps teams and what I've seen at many customers, is we often stop after the deployment to production. We often take a kind of narrow view of the development value stream. What I've learned in the last few months, I must admit, with our products but also with our customers, is how can you go beyond post-deployment? Can you use, for example, observability tools that are often used to manage the technical health and understanding how the application is used to feed data back into product management? Or can you use your security vulnerability scanning to feed into your product manager to make better decisions on the capabilities that you need to add?

Building the loop from deployment to monitoring back into the roadmap, I do believe, is really important. We're lucky in these days because we have almost all of the monitoring out on all of our applications. Here's my tip: do a little team exercise tomorrow or next week, whenever this conference is over, to start looking at the monitoring data and take that and see what you can use to give as feedback to the product manager. Where to optimize, or where can we gain a better retention rate throughout the entire flow? That is really important, I believe, to start getting a much more complete view of the entire software development, delivery, and operations process.

The second tip that I do want to discuss here is discussing with your business partner the success of an initiative. What is the outcome that you want to achieve while developing a new capability? I've learned that this is so important because we've discussed in the beginning of this presentation that you need to understand what the goals are that you're contributing to. But how do you know, as an engineer or a team or a product manager, the goals that you're contributing to from an organizational perspective? Everyone from the CIO all the way to the engineer has a different lens on how they look at reality, but also on what is value creation.

What I've learned is that understanding and having the conversation with your business-line manager or with your product manager is super helpful to make better decisions. Why? Because you understand the purpose: what is it that we want to achieve? Within that framework, you can make a better decision. What I can propose is that together with your team, you start filling in this little table. How is work going down from product manager, or even from the line of business, to engineering? What is the work that we're contributing? Then, and that's the interesting thing, how do we deliver value back up?

For an engineer, from a pure engineering perspective, you can say, "My value delivery is the merge into the master branch." Or from a team, "As soon as I've a new artifact ready, my value delivery ends." But that doesn't mean that the objective from the organization is achieved. Before it's in the hands of the user and we've rolled out the entire offering, including the marketing campaigns on television, there's no value delivered. Understanding how your work contributes ultimately to the value delivery is eye-opening. The thing I've taken out of this is I can make better decisions in the bigger picture. That is what I believe is really important if you are beyond the first year of your digital transformation.

The third one is probably a little funny one, but at the same time it is super serious. Taking time to recognize waste or discover bottlenecks is really important. I can promise you, these bottlenecks go beyond your pipelines. It's powerful to have a tool that visualizes where the bottlenecks are, where you can accelerate if you automate, or where you can accelerate if you take reruns out. These are all kind of the basic efficiency improvements.

But if you are beyond your first year of the digital transformation, and the majority of us are beyond that first year, take a serious look at your agenda. In particular, these days of all of us working from home, it's sometimes crazy. There's so much work crammed into that one day. Is it really needed, all these meetings, or can you focus back on delivering the work that needs to be delivered?

Another one I do want to highlight is what I've called the delivery bumpiness. We all know that pushing out one pipeline is probably not so hard. But what I've learned is, if you really, really want to accelerate, the simplification of your entire application stack is really important. Many of us are still facing complex deliveries, and they are hard. If you need to align five or 10 pipelines all together, that is really difficult. You can do so through automation; I know there's an offering also in our portfolio. But what is important, I believe, is to simplify the entire application stack to make ultimately the delivery much more easy. Ultimately, every CI cycle, that should be the ultimate goal, can go and needs to go to production. The focus on the simplification of this is a hard one. It's a long journey, but it is an important one ultimately to accelerate.

Last but not least, I cannot emphasize this enough. It is really important to understand what you want to achieve. It sounds easy, but it is hard to get it on paper. It's hard to articulate it all together and to align and collaborate around the same set of goals, the big ones on the long term and the next goals that are achievable within a quarter or within months. Aligning what you want to achieve with the impact you want to make with an organization, identifying the outcomes, is the second thing.

However, if you are able to map out the goals in alignment with what you want to achieve as an organization, you can truly accelerate. This is important, I believe, if you want to move forward in your digital transformation. You simply need to understand where do I want to go and what is it that I want to achieve? These are instruments that are really good and really helpful to make that happen.

It will take time. You need to go through it. You need to exercise it on a quarter-by-quarter basis. You need to follow the rules on a daily basis to execute upon the actions. But if you do so, you will notice that you will go faster and faster in this digital transformation.

The beautiful thing is, what you will also learn is that there's much more in the improvement cycle than just the automation. There's a lot of stuff happening in the ecosystem, in the atmosphere of teams, and in alignment with your business partners. However, if you're able to do it, you will achieve whatever you need to achieve. That is what I think is powerful in a journey. I do wish you all the luck. Remember, it's a journey. There's never a goal. It's always on the way towards a new destination, and therefore, just enjoy it.

Thank you for attending this session. Please go to our virtual booth. I will be there today as well a couple of times, and if needed, I will come into the booth because there's always someone from us. Thank you.