6 Concrete steps to get you started with your journey. First things first. This blog is something subjective. I like to share my experiences, my knowledge and my way of working with you to inspire you. It’s definitely not my purpose to say this is the best way of working. I’m human and I make mistakes as well. Try to read this objectively and pick the things that are valuable for you. Leave the things that seem less important to you for what it is. Of course I’m very interested in your feedback and I would appreciate it if you want to leave a message at the bottom. If you think this is valuable for you, feel free to share on your favorite social media as well.

And now, let’s move to the content. Are you thinking about starting with DevOps? Or probably you’ve already started with your DevOps journey recently but you don’t know how to continue? Or you are overwhelmed? Then this blog is certainly something for you. With great regularity, I get questions like: “where to start with DevOps?” Do you have to start with the team? Or first the management? Or maybe tackle the processes first? Or rather start with Cloud or implement CI/CD? Or maybe just start with Test automation.  A lot of choices and therefore people have choice stress. They don’t have any idea where to start because there is a lot to be improved.

Therefore I’ll tell you in this blog 6 concrete and effective steps to get your DevOps Journey started.

Step 1: Take a motivated team

Step 2: Choose a pipeline which the team uses the most.

Step 3: Make a VSM of this pipeline together with the team.

Step 4: Prioritise all improvements that arose from the VSM.

Step 5: Translate the improvements to user stories and post them on the backlog so that it flows into the existing process.

Step 6: Improve at least 1 thing per sprint (assuming you work with Scrum).

Step 1

What I advice most of the time (but of course this depends on the context) is to start with one team. If you have more teams in the organisation, just let it be and start with “only” one team. Babysteps! With small steps you can work on improvement and optimisation. A baby can’t walk immediately as well. First of all standing upright carefully, hold on to things and from that point; little steps and the first steps without holding on to something. It’s about falling and rising: just like the baby who’s learning to walk.

As soon as you’ve decided to start working with a team, take the team that’s most motivated. This will accelerate the successes that will be made. If you feel resistance within the team, you should read my blog about resistance.

Step 2

Ok, and now? You have chosen a team. A team with enthusiastic and motivated colleagues. They are willing to start with the DevOps journey. 

But then, where do you start with that team? A VSM, you’ll start with making a VSM. This means Value Stream Mapping and is originated from Lean. It’s about visualising a process and determine where the delays are centered. The bottlenecks, waiting times, the transfer moments, the lead times and the effective execution times. 

A VSM is a very useful way to: 1, provide insights in where the bottlenecks are located, but 2, also to get the conversation started. You want to have a sincere dialogue with the team about potential improvements.

By starting with one team, you’ll get a lot of useful information from the conversation. What does the team walk into when it comes to decision-making, business processes, bureaucracy? 

All points where value can be achieved. 

Step 3

Nevertheless, these are things for a later moment, let’s start with making the VSM. 

If the team has a pipeline, or maybe even more pipelines for their products, just choose one. The pipeline that they use the most. This is the starting point for the VSM. 

OK, you’ve got your team and you’ve got your pipeline. Let’s actually start with the VSM.

At the moment of writing this blog, we’re in a lockdown because of COVID-19. Most people work from home. This can be an advantage or a disadvantage but I’ll leave that out for now. 

However, this means we have to do the VSM “remote”. The team members are at home working from their computer and that means we have to use different tools to visualise the pipeline. This time it won’t be an actual whiteboard with stickies but a digital whiteboard with digital stickies. 

Meanwhile, I became a great fan of MIRO. In my perspective this is THE tool for online collaboration. For brainstorm sessions, creative sessions, retrospectives and so much more. And at this time for working out the VSM online as well. 

What are you going to process in the VSM? I always think about a developer who’s going to check-in “something” of his/her laptop or any other workplace. That “something” is most of the time a line of code or multiple lines of code. 

For example, it could be a feature or an adjustment. Anyways, the developer is always checking something in. That is the starting point of the VSM. As soon as it’s checked-in, the question should be: “what is the action that takes place right after?” And, make sure this is small and concrete. This is one transaction, one action and not a bundling of transactions or actions.

You want to make sure this is super detailed. This action or transaction, is it a manual action or automatised action? If it is a manual action then we color the square red in MIRO, so it’s visual clear that it’s a manual task.

Before we can go on to the next action, we want to know a few things. Is something called? A call to external systems with the help of API for example? Because that’s also something we want to have insight to. 

If that’s the case, you want to process this in the VSM as well. However, only mention that an excursion is being done to an external system. For the rest, we don’t do anything with it yet. 

We go back to the first square after the developer checked in his / hers line of code.

What is the first next action or transaction after this square? Is this a manual action again or is this an automated action? If it is an automated action, we make a blue square of it. Now, you start to see the contouring of the process of the pipeline. An icon with a laptop, a couple of squares with actions. 

Now, we want to know what the transaction times, lead times and waiting times are.

At every square there is a transaction time. This is the time that’s needed to process one. This could be calling an API, running one or more tests, it doesn’t really matter. We want to know how much time is needed to process things before it’s going to the next square. This time can be estimated. Doesn’t need to be in seconds. An estimation in minutes is enough for now. Now we know what the transaction times are, we want to know what the waiting time of the first to the second square is. It could be that there is no waiting time at all, but it could also be that a time out build in. At least, we want to know what the waiting time is, in case there is a waiting time. Now, we want to know the lead time. This includes the transaction time and waiting time.

We’re going to completely finish this process, from visualising the actions including the waiting times, transaction times and lead times until the production environment. We want to know exactly what types of actions and transactions (manual as well as automated) are needed to let the lines of code land in the production environment. Because, if it’s all good, these lines of code will deliver value to the customer/user.

This exercise is called a VSM: “making a process visual and providing insights into this process” and at this moment, it’s a pipeline of a development team.

Step 4

But how to continue? You want to prevent it to get hidden in a drawer. So, you want to make sure it becomes part of the existing process of the team.

Now, you’re going to determine with the team what the biggest bottleneck is. And this is easy because the times are mentioned and we provided insights in where the manual actions are and where the automated actions are.

The thing they suffer from the most will probably be a manual action. That would be improvement #1. 

Thereafter, we identify all the improvements and we write them down. It’s easiest to write it down immediately as an user story and place it on the backlog. 

We want to prevent this exercise from being in someone’s drawer all of a sudden. So immediately place all the points of improvement on the backlog as an user story.

Step 5

While writing down these improvements, keep in mind the priority. What’s the team suffering from the most? Because that’s the user story that will be at the top. 

Now the VSM has been made and all the improvements are being placed on the backlog as user stories, you’ll probably be 2 or 3 hours later. Time to celebrate! You have made your first steps in embracing DevOps in your way of working. You have gained insights in where the potential improvements are and prioritised them. You have also secured that there will be looked after within the next periode because it’s on your backlog with the right priority.

Step 6

Alright, final step! You’ve made a VSM, identified improvements and those improvements got the proper priority.
The most important part is up ahead, actually doing something with these improvements. Pick up the work, improve, optimise and decrease technical debt.
Because this is DevOps folks, picking up small tasks which will result into value for the customer and / or users.
To ensure that these identified improvements are actually taken up, make an explicit agreement with the team on how many and how often these improvements are implemented.
My advice, this must be a structural part of the work. So not once in a while, no, continuously!

Every sprint, assume that you work according to Scrum, in every sprint there are a few stories that lead to improvements or reduce technical debt. At least 1 per sprint, but preferably more than 1.

If you work Kanban or scrumban, make sure that at least 1 work item from the WIP is an improvement.

So, recap:

Step 1: Take a motivated team

Step 2: Choose a pipeline which the team uses the most.

Step 3: Make a VSM of this pipeline together with the team.

Step 4: Prioritise all improvements that arose from the VSM.

Step 5: Translate the improvements to user stories and post them on the backlog so that it flows into the existing process.

Step 6: Improve at least 1 thing per sprint (assuming you work with Scrum).

This was it for this blog. I hope this helped you. If you have any questions or comments, let me know. If this blog had any value to you, for example new insights, feel free to share it on Social Media.