DevOps

DevOps: What comes first the culture or the collaboration?

Blog, Leave a comment

Much has been written on the subject of corporate culture, more has been added since the advent of DevOps. Luminaries such as Patrick Debois, Gene Kim and Jez Humble all talk about DevOps and Culture on a regular basis. Every organisation I’ve worked in has been obsessed by it’s culture. After 20 years in small startups and global enterprises I’ve come to the conclusion that culture isn’t something that can be controlled, measured or managed directly.  This gives me a great excuse to paraphrase one of my heroes the late great Sir Terry Pratchett: “THEN TAKE THE UNIVERSE AND GRIND IT DOWN TO THE FINEST POWDER AND SIEVE IT THROUGH THE FINEST SIEVE AND THEN SHOW ME ONE ATOM OF CULTURE…”

Culture is created as a by-product when we work and play together, the nature of our culture is determined by our purpose and habits. A group that is encouraged to learn from failure and improve as a result will be curious and innovative. A group that only looks inwards for help and is discouraged from interacting with other groups will become defensive and narrow-minded. Groups have a tendency to reach out to other groups when they can speak the same language and have the same goals. Groups tend to become defensive when they perceive they have different or opposing goals to the groups around them, they take on a besieged mentality when they don’t even share terms of reference with the groups around them.

If you want to change a group’s culture you need to change how they work together, how they work with others and the habits they share. If you want a culture of innovation you should expose people to foreign ideas and concepts by creating the opportunity for groups with different skills and perspectives to work together on proposals that will become new projects. If you want a collaborative culture you should create the projects that require people with different skills and perspectives to collaborate.

As far as I can tell, there are currently two successful DevOps models. The directly collaborative cross-functional team model that encourages groups to work together to deliver services and the Service/API model that encourages groups to have rapid, predictable interactions by presenting APIs to each other. If we want collaboration we must break down the silos and allow engineers with different expertise and perspectives to work together. Consider a monitoring/feedback project where software, operations and test engineers work together to delivery better quality tests and monitoring. If we want groups to communicate with each other’s services via API calls we need to ensure all groups have the resources necessary to create good quality API’s. That includes Network, Operations and Test functions as well as focusing on the APIs between services and between clients and services.

The choices we make about how our teams work each day, the things we encourage them to do in the morning (whether we encourage them to check out the quality of the service or just look at their teams project progress) how we encourage them to behave when they make a mistake all contribute to the culture we create. We choose our culture when we decide how our teams work together and what we ask them to focus on and the opportunities we present them to learn, grow and receive recognition. In my experience DevOps happens when the opportunity exists to collaborate.

DevOps accelerates the rate at which the opportunities to collaborate present themselves. When I joined Playfish the Operations team existed as a service provider to the game and platform teams. Operations then built a few tools and shared the code with the games and platform teams and that created a few opportunities for operations and software engineers to work together. As those collaborations yielded more and more interesting and valuable results the level of collaboration increased as did the quality of the service that was provided. This then made more software engineers curious about operations and that yielded more opportunities for collaboration and learning until we had some teams that were almost entirely self-reliant for their regular day-to-day activities that made more space for greater levels of collaboration and so on and so on…

I write a lot more about how to build and foster collaboration in IT organisations in my book Next Gen DevOps: Creating The DevOps Organisation. Available on Amazon now.

*Image credit: Yoel on Morguefile

Next Gen DevOps Transformation Framework Update… Oh dear

Blog, Leave a comment

Since I started working on the framework I’ve had the idea that I wanted there to be a visualisation of the entire framework.

I have a visual imagination. I’m most comfortable considering the big picture and I wanted to give people, like myself, an at-a-glance view of the framework. I also thought it might help people understand the scale of the framework and help place their organisation within it.

I’ve had four major attempts at this so far and I think I’m getting there. Unfortunately the Scrabble people might sue me if I go with this version :):

NGDOTF Capability Web v0.2

Don’t start projects in the bloody middle!

Blog Leave a comment

There must be millions if not billions of words published online about how to start a new project.

I know there are because I read a lot of them before I started writing Next Gen DevOps: Creating The DevOps Organisation.

Most of these articles can be boiled down to two main pieces of advice:

1. Step back from the project and look at the whole domain and then create a structured approach.
2. Dig in a little and get started until you get a sense of the complexity of your project and then step back again and take a second look.

So why does everyone starting a DevOps transformation immediately get cracking on Continuous Delivery?

It’s, arguably, the hardest technical activity in a DevOps transformation. Continuous Delivery in an enterprise with even a couple of years of legacy might involve the orchestration of hundreds of configuration items, the management of thousands of variables and an extremely complex validation process to ensure everything works as it should. There are organisations out there who still aren’t benefiting from reliable continuous build processes who are nevertheless downloading configuration management tools and starting to code the management of application properties. There are still businesses who consider testing to be an entry level role who are trying to get their entire estate to deploy continuously multiple times a day.

Don’t get me wrong I’m all for Configuration Management. If you can get that nailed you unlock a vast amount of potential, it’s just that it’s starting in the middle of the project!

I don’t know where your organisation is or where your strengths and weaknesses lie but before you start building building complex models for divining properties and environment variables you could consider configuration files as artefacts. Manage the creation, modification and deployment of those like you would your applications. You could also ensure you have your deployment tools in version control and treat them like you do your revenue generating services. Manage the development of them with stories and ensure their development keeps pace with the development of the services they need to deploy.

If you really want to push the bleeding edge you could include systems and testing experts in your development projects and ensure that your testing, monitoring and deployment capability is as sophisticated and as capable as your revenue generating services are

Good luck out there and feel free to drop me an email if you need a hand.

Oh and if anyone is wondering about the featured image, that’s my Dad teaching me to climb trees. If the reference is too subtle you start climbing trees at the bottom of the tree where it’s simplest but sometimes hardest to get a good grip :).

Next Gen DevOps Transformation Framework: Project Update

Blog, View all 2 comments

I have completed a very rough first draft of all the individual elements of my DevOps Transformation Framework. The framework intends to mature nine functions required to build and manage online services. They are:

  • Build & Integration
  • 3rd Party Component Management
  • Feedback Loops
  • Software Engineering
  • Test Engineering
  • Project Management
  • Incident Management
  • Change Management
  • Budgeting

The framework takes each one of these functions through a series of steps (projects) which improve the capability and productivity of each function. Yesterday I submitted them to the first test process. I wanted to make sure that while each step might refer to other steps preceding it or assume capabilities in other functions at the same level they didn’t assume any capabilities only available at later levels. I did this in a distinctly old school way. I printed them all out, cut them up and laid out the starting point or capability level 0 as I’m calling it at the moment. This effectively defines the prerequisites for starting a DevOps transformation. I’ll publish more on that later. Framework_lvl_0 I then randomly selected capabilities from the next level (level 1 funnily enough) and made sure nothing was assumed that wasn’t already present and continued until I had laid out all the capabilities for each function. framework_lvl_4

I still have a long way to go yet. I need to confirm how far each function can mature before it has dependancies on other functions or what the impact might be if capabilities are introduced in one function before another. The next big task is to present one view showing the complete matrix of functions and capabilities and describe the advantages that result when they combine. For example: what advantages are available to an organisation when support and maintenance tasks result in use cases or user stories AND basic automated tests are available to be executed by anyone in the organisation. I’m getting close to needing some help to get the framework into a fit state for public review (and hopefully contribution). As such it needs a little peer review first. If you’re interested in working with me on creating a framework to help businesses transition to DevOps please drop me a line at grant@nextgendevops.com or tweet me @grjsmith or @nextgendevops or if you really must message me in Linkedin!

Where are the CTOs?

Blog Leave a comment

For the last 5 years I’ve led DevOps transformations, consulted with small and medium businesses and large enterprises. I’ve written a book and I’ve pitched that book just as hard and as far as I can. That’s meant attending and presenting at conferences, participating in group discussions and attending events such as CA’s DevOps influencers dinners.

In all that time I’ve met with the handful of CTO’s who are personal friends and one who was the organiser of one of the events but that’s it.

DevOps is without doubt what is shifting the needle in the Technology industry right now. The Puppet and Thoughtworks State of DevOps 2014 report and Harvard Business Review’s The Leadership Edge in Digital Transformation report confirm this. If more evidence is needed one only has to look at the investment Thoughtworks, HP, IBM, CA and others are making in tooling and consultancy. And if that isn’t enough the nearly 200% growth experienced by Chef this year make it clear where much of the biggest 2000 companies are making their bets.

And yet the very people who should be creating the strategies that drive DevOps transformations and that lead to investment in new tools, training and that support the necessary cultural changes seem to be absent from the discussions.

I regularly speak to enthusiastic engineers and line managers. When I’m invited to speak to companies directly I’m almost always invited by the engineers. Sometimes they manage to bring their managers along but only once have they been able to bring the budget holders and decisions makers to the meeting.

On the other side of that fence, I get several calls a day from recruiters who are on a never-ending hunt for DevOps Engineers. They are routinely frustrated that they can’t enter into a dialogue with the CTOs they’re hiring for to find out how the company strategy is evolving to support a DevOps transformation. They need that interaction to be assured that someone isn’t asking for DevOps when they actually need System Administrators. Nothing annoys a recruiter more than working hard to present candidates and for those candidates to leave after just a few weeks because the hiring organisation misrepresented the role.

So if you know a CTO then tell them to get in the game! Ask them what event they’ll be attending to learn more about DevOps. Ask them what groups they’re members of and who they follow on twitter. Tell them to take a look at my book or drop me a line. If they look at you funny tell them that it’s already true that the businesses who are evolving DevOps practices are already outpacing those that aren’t and it’s time to jump in and swim or count the days until they’re washed away.