Pitfalls for DevOps teams

So, what does it actually take to set up a successful team? Of course, you just tell them to, they will do it! It might be as simple as that to you, in my experience just saying something is running DevOps did not necessarily make it so. It’s counter-productive, and more importantly, it does not help. Like with every practice, it all starts with realizing you don’t do it because others tell you to, you do it because it makes life better for you. In the past years, I’ve been a part of many transformations running the full gamut from waterfall, prince2, scrum, and DevOps. Although it’s good to see all the improvements and added experiences over the years, some of my best lessons come from the failures. So let’s start learning from all the failures I’ve come across… First of all, what is DevOps? Some manager explained it to me once as the team fixing its own bugs that come from operations. To me, that was as far removed from the truth as saying that to be a manager you must attend meetings. Of course, it’s true, but far from the truth. Devops means the team takes responsibility for every aspect of the application. Its features, incidents, operations, monitoring, deployment, availability. It’s basically an integration of the software development processes with the classical ITIL processes. The responsibility required to fulfill these processes means the team needs a broad set of skills. As a team, you need to be able to do everything yourself. This includes responsibility of used services, any third-party components, any acquired skills. Know that not every member of the team needs to know everything, but as a team you will need to fill the gaps. As a team, you will find out that being a member of a DevOps team is not necessarily a nine to five job. It means agreeing with your team members on holidays, giving support past business hours, running a standby shift on the holidays. It should go without saying that, to give this level of support, automation is key. You need to be able to do a controlled deployment to production in minimal time. To enable this requires all things you already know about: automated deployment, unit tests, integration tests, code coverage, and quality control. Though this was advised in scrum, it is an absolute must for agile. And here is the most difficult part to any DevOps team, and where you need the whole organization to succeed: manage your workload on one single backlog. If you’re still doing scrum with tiny waterfall burndowns: don’t switch yet! You will soon find yourself doing larger waterfalls, congesting the system. Feed all your work to one backlog: new feature requests, incidents, feedback from the quality system, the monitoring system. Make prioritizing a continuous process to keep your backlog in control. Make sure to deal with every backlog item swiftly and deploy, deploy, deploy. Remember: doing DevOps is not a sprint, it is a marathon. Catch your speed, get into the runner’s high and enjoy the ride! Image source