Isn’t it funny that a lot of people, me included, don’t really know the difference between DevOps and Continuous Delivery? Wikipedia tells that both are pretty much overlapping. In order to continuously deliver one must be familiar with DevOps. Anyway, I will tell you what you can do now to start with DevOps and Continuous Delivery. Here are 9½ simple approaches that tell how you can start immediately.
Start Educating Stakeholders in DevOps.
DevOps is very hard work, especially for large organisations where I’ve been working for the last couple of years. It requires enormous amount of effort to make everyone know that this whole DevOps Thing creates value for everyone. “Devops Thing” is the term most of the people say when they don’t know what it means. It is our responsibility to educate them so they will understand that everything we do is because we want to increase the value of our business. And this implies of course that we need to create value for our customers and invest in our IT.
I was once part of a project where we rewrote a huge application. Actually we split it up into multiple applications and automated the whole process, starting from committing the application code into a common source repository, well it was GIT, and ending at the stage where we can release the changes when we want to. A lot of people were involved and it took quite a while until everyone understood the value of it even though the customers didn’t notice any changes after that, design hadn’t change and why should it.
Continuous Education, another “Continuous X” is a simple way of starting the cultural change in an organisation. DevOps will save you from many political discussions. Teaching all involved parties is super important in order to really gain from the advantages of DevOps and Continuous Delivery.
Start Building Small Applications.
We build small applications faster than big applications. That’s a fact. Small applications are also easier to test and maintain than big applications. So, why do smart developers still build applications that do many things and ergo become big?
I remember the first years as a Java developer. It was and it still is a great feeling when I have achieved a milestone and maybe got something great done. I wanted to show the senior developers that I could handle the application others had worked on for years. I fixed a bug and I also added a great new feature that hopefully will make the life of the users easier. Yeah, until it went into production and caused a real problem for them.
I assume every developer had at some point in his or her career experienced such a fail. That time I blamed me for the troubles. Later, I blame the application for being unmaintainable. Today, I know we need to write small applications that are testable and maintainable easy and fast. It is in our power to change todays ways of working. For now, start building small applications that do little.
Use a Static Code Analysis Tool.
Quality matters, always. Especially when you are going to automate processes. Whatever we commit to the common source repository might be a release candidate.
Did you ever release a “println” or implemented a method that had too many lines of code to be understandable by anyone into production or anything alike that maybe was totally unnecessary and maybe also causes problems in production? Then you are not alone, I did. Static code analysis tools can eliminate those kind of problems.
I wish I could start with “Some years back I …” but the truth is: A week back I committed a “println”-statement that went into production without anyone noticing it. The method that contained that statement was neither tested even though it contained some simple business logic. It is this kind of mistakes or should I say lazy behaviours we easily can avoid.
Make static code analysis as part of your processes. It is a simple step towards a better application. Start now by analysing some tools.
Make Processes Visible
I need to know everything! I need to be able to continuously improve all my processes. I need total transparency. Sounds a bit dramatic but it’s the truth. We need to understand how we work together. All stakeholders need to understand the strengths and weaknesses of all the processes. Only then will we be able to point out the missing parts and the parts that need to be removed or adjusted.
One well known and simple approach to this is it to have an overview over all ongoing tasks and the people holding them. It’s well known so I assume you all do that already. We have also a Scrum Board that shows our activity. Actually we run Kanban but never mind. So, that’s a great little step that we all should have in place. But are also all stakeholders, just to take another example, aware of how we handle an incident in production where things have to go lightning fast? I assume not. Quite often time goes by and we are busy explaining people the setup of the architecture that has problems instead of focusing entirely on solving the causing problem.
If all processes would be visible and well known to anybody like how to handle an incident, time will be spend wiser and problems will be solved earlier. We got a confluence page where we describe everything very simple about our environment and our applications. Everything that might be needed in case of problems can be found here. Maybe you create such a page on your own. The great thing about documentation is that you can spot areas to improve. So, the first task is it to document your setup. The other is it to go through it with all stakeholders. Maybe they spot something within your architecture that might be a candidate to improve. Start now and document all your processes and everything that is important to have when time is rare.
Measure As Much As You Can.
What is the average lead time of your tasks from starting developing to be release ready? What is the response time of your services? How much time does it take to expand your cluster? If you know all your numbers you might know what you need to improve.
Imagine one of your applications stops responding because of an OutOfMemory-Exception like we once had. We didn’t have anything that could have warned us. Instead, our customer service got a lot of phone calls from angry customers. Would we constantly have measured the used memory of this application we would probably have reacted earlier. We would not had to attend an expensive and time consuming task force meeting and our customers neither would have become angry.
There are plenty of monitoring tools out there. Start to look at some of these and you will very soon know your numbers. We do now, and whenever something starts to go wrong we receive a notification. But even if you have such a monitoring tool very soon in place it can take a while before you have configured it right and not get too notification from alarms that are no problems.
Make Value Visible.
We create value. That’s how we earn money. And that’s also why we need to track it. Nothing is more important than to know about the value we create and for whom.
Very often people say that they need to improve their product but when asking them why, they don’t lose a word about the value behind it. We all want to increase the value of our business. And we all know that we need to create value for our customers in order to increase the value of our business. But what about making IT more valuable so maintenance costs go down and new product launches are smoother and cheaper? Working on technical debt. We all know about it but we don’t talk about all three values separately. We only talk about “The Value”. But if we differentiate value we can get more out of it and make value more visible.
Business Value, Customer Value and IT Value are tightly connected and need therefore to be seen by every stakeholder so that they can talk together and understand their reasons for doing what they are doing. It sound maybe easy to just talk about something but it is not because we need first to have data we can talk about. Start collecting data that can be used to measure value of any kind. I will later post a more detailed blog entry about “Value” on my site sven.malvik.de/blog but for now just start to think about what data you need to measure and then get it.
Celebrate Success.
People. It’s all about us. I’ve worked in IT now for over a decade and I always have been part of a team. I believe that we change our jobs not only because we want to face new challenges. I believe we change our jobs often because we don’t feel a strong connection to the people we work together with anymore? Maybe I’m right, maybe not. “I love what I’m doing and I love doing it together with my colleagues. My colleagues are my real friends. They are family”. That’s what we need to say when we talk about our job. Does that sound crazy to you? It probably does. It probably is 😉 But here is the thing. DevOps is very much about the people we work together with and it’s about how we collaborate and that we trust each other as much as possible. I’ve not joined the army but from what I’ve seen and heard they are very good in building teams that stick together, always and forever. The ultimate goal should be to do everything what is in our power and to do everything that’s needed to want our colleagues and friends to stay.
So, how can we do that? There are companies that try to create kind of family, almost a sect. That is scary I know. Those teams spend a lot of hours together not only working but also outside working hours. I guess we don’t need to be too extreme but here are some advices from smart people about how you motivate your team after a success and that’s great for now because we first want to start.
- Go out for dinner.
Get together as a team and enjoy your achievements as a team. Celebrate it and hold a short talk about what you all have gone through and the barriers you managed to go around. Send a clear signal to everybody within the team that the job is done and say: “Yes, we did it. Thanks to all of you!”. - Personally Thank Each Team Member.
As a Project Manager you should show your team your respect whenever they have done something great. Keep in mind that you need the team, you report to senior management and must ensure that the team keeps doing well. Tell each member how much you appreciate their commitment. They will appreciate it as much as you do and probably keep doing well because they feel they owe you. - Reward The Team With More Flexibility.
One way of rewarding a team is to tell the team members and to show the team members that you trust them and that you would like to give them something that underlines that, more flexibility. More flexibility will give a team more freedom and it will give them more time to develop themselves. You reward the team with more flexibility and will in return get an even more motivated team. - Celebrate With Senior Management.
A genuine thank can leave a more lasting impression and it will leave a deep entrenched respect. You don’t need the senior management to stay for very long. It’s just that they show up and say some words about the great effort and the importance of having great teams.
Once again, become real friends with the people you work with. You probably spend more time or the same amount of time with them as with your own family. Have fun and celebrate.
Invite The Operations Team.
I want responsibility. I always wanted responsibility like many others. Some years back I got responsibility for the production environment for a start up company I worked for. Actually we all were responsible. But that’s not the point. The point is that we run the entire chain from dev to ops. We were responsible and we owned the system. Unless you work in a small company like I did you probably have a operations team that you never have met? I met the guy from the ops team one year after I started in a larger nordic organization. Everything outside our test environments was like Africa, a huge area I am not familiar with. But I really wanted to so I feel a stronger ownership. After a restructure in this organization I worked for the ops guy became part of our team, a great change. Suddenly our services and apps go out into production in a speed I never have seen before in that organization. It is like magic having ONE TEAM that does everything.
As a starting point the operations team should visit your team. Start to collaborate and really work together. Try to get as much responsibility as possible.
Release One Feature at a Time.
Murphy’s law says: “Anything that can go wrong, will go wrong.”. And we all have experienced it many times. Just for a minute, imagine you released two applications and at the same time upgraded some firewall rules. Now, the system doesn’t respond anymore, ops. As an experienced developer in that particular area you’re probably lucky and find out the route cause of the problem pretty fast. But in a larger organisation with many silos it can become a real problem. Some weeks back I was one of 10 people joining a Task Force meeting trying to find out where requests were hanging. There are firewalls, clusters, load balancers and proxies and there are many, many people involved. Without talking together and working together you might end up in a mess. It sometimes felt like that. But there is not very much you can do about it except from changing the routine within the area where you are in charge. You can control what you release and you probably also know some people from other areas. Talk to them. Get to know each other. But most important make sure you know what fails when something fails. Limit the amount of changes that goes out to production at the same time. Rease one change after another. Be safe.
½ Step of Starting with DevOps.
I know you can’t start with all 9 suggestions I made in this article at the same time. I want you to pick one of them. Pick the one step you feel most comfortable with and start working now. I always need one very tiny little task to really being able to go the entire way afterwards. Maybe you feel the same way. Happy DevOps.
