Jaap Schuttevaer did a workshop on DevOps at the Agile Testing Day Netherlands 2015 conference. The goal of the workshop was for the attendants to experience the Dev & Ops and DevOps approaches. How do they feel about these approaches, what is the impact of DevOps, and what are the advantages and disadvantages.
The attendants were split in groups, the assignment given to the groups was to transport balls from one area to another. There is a 2 meter distance between the areas. The users are in the two areas, they may not walk with the balls and not pass them over. So they need a tool, a solution to get the balls transferred.
In the first round Schuttevaer provide job descriptions for the teams and users using a separated Dev & Ops approach. The users and the Ops members were sent to another rooms, Dev members (developers, analysts and testers) remained in the room. Each team had a delivery manager who was free to walk between the two rooms.
The development members got a box with materials and user story to build a tool to transport the balls.
As a user I need a device to stop balls at the end zone,
so that I can transport more balls per minute to the stopping zone,
because I want our team to win.
Meanwhile in the other room the users were experimenting to think about the solution that they needed. For instance some tried to throw the ball to hope that they would end in the delivery area and stay there.
The delivery manager walked between the development members and the users and operations to check the solution that was developed. When seeing a first solution they asked for an operations manual, as the operations members would need that to install the solution. Later a new requirement was added: there should be no user interference in the solution. The delivery managers of the groups did a lot of walking around to communicate the needs of the users and operations to the developers and check the solutions provided by the developers.
One of the development teams created something that would stop the balls when thrown into the destination area. Another team creates a track with borders to guide the balls. The question arose how difficult it will be to deploy these solutions. Which turned out to be the case when the operation members tried to install it using the manual. Meanwhile the users had to wait until it was ready, and the development members were waiting for feedback to see if it worked or not.
For the second round a DevOps approach was taken. Everybody was now in the same room, analyst, developers, testers, delivery manager and operations. Quickly the teams decided to move to the operations room to discuss and try different solutions. Developers and testers were building a solution together, the users tried it out and gave direct feedback to the DevOps team.
Now that developers and operations are working together with a DevOps approach it became clear how the solution should be installed. No manual is needed anymore as the developers can help to install it.
The solutions developed in the second round using the DevOps approach turned out to be better for both teams, more balls were transported when they tested it.
During the debriefing Schuttevaer asked the attendant how they had experienced the Dev & Ops and DevOps approaches. Some of the conclusions were that delivery managers had almost nothing to do in the DevOps approach and that the DevOps teams had better coordination where people talked and helped each other since they were in the same room. Developers know what operations is doing in a DevOps approach, which helps them to develop a better solution. One attendant mentioned that DevOps is a complete different way of organizing the work, which makes the result completely different.
InfoQ did an interview with Schuttevaer about what DevOps can bring to organizations, tearing down the walls between Dev and Ops and asked him for advice for organizations that want to apply DevOps.
InfoQ: Can you share your view of what DevOps is and what it can bring for organizations?
Schuttevaer: DevOps is the name of the game of merging Development with Operations. When organizations adopt Agile, for instance by implementing Scrum or XP, the initial focus is on the development side of Product Development. One of the main challenges to tackle in that phase, is to tear down the walls between expertise silo’s, formalized in job titles like: analysts, programmers and testers, and make them work together.
After the first struggles to get Scrum working, the development teams appreciate the fast feedback cycles and want to push this further. Typically the development teams want to be able to get new features into production within each sprint. Thoughts like implementing Continuous Delivery come into their minds.
It then becomes apparent that there are some nasty walls to climb within the organization. Walls that are major obstructions to getting a newly developed version of a product to production. These walls are all due to the separation between the development department and the operations and maintenance department.
InfoQ: Can you give some examples of walls that you have seen between Dev and Ops?
Schuttevaer: There are several types of walls to tear down. The first one, and in fact the root cause of many other ones, is the organizational one. Typically larger organizations have decided to make a distinction in their IT organization into "change the product" (Dev) and "maintain the product" (Ops) departments. The downsides of this decision are numerous. Each department gets staffed with managers and employees that have specific mindset, responsibilities and performance goals: Developers will be focused on creating new functionality and Operations on maintaining stability.
In many cases there is also a physical separation: development and operations people are located at different floors or even different buildings. And the organizational separation also results in an "us and them" attitude – the hilarious system of development trying to throw "development done" stuff over the wall to the operations department, and the operation department trying to defend themselves with huge lists of "Production Acceptance Criteria" and accompanying checklists to be filled in: "contracts over collaboration".
InfoQ: What was done to tear down these walls?
Schuttevaer: The main reason for these walls is in the organizational separation of development and operation into disjoint groups. To tear this down, and to realize close, transparent cooperation between Dev and Ops people, the organization needs to change. This does not (directly) need to be an hierarchical change. It may start with a functional change. So, start by implementing DevOps by extending Dev-teams with Ops people.
And that may sound easy, but this does come with quite some challenges. Putting people in one team room, does solve the physical separation issue and communication may improve. However there are some more fundamental things to overcome. Do mind that developers have little understanding on, and mostly no experience in, tasks, tools and responsibilities that operations people have. And vice versa. Mutual understanding and collaboration does not come for free. This must be stimulated and fostered. Also the "new" Ops team members have not experienced the learning Scrum experience that the Dev team members have had. And beware that most people do not directly embrace change.
InfoQ: Can you give some advice for organizations that want to apply DevOps?
Schuttevaer: If you want to apply DevOps, there are many advices to give. Most you can derive from what I already stated: reduce the physical distance, take into account that change comes with fear and takes time, remember that Ops people are not as experienced in working with an Agile mindset as the Dev people have already learned.
I also advise organizations and Scrum Teams that want to implement Continuous Delivery to bear in mind the first Agile Value: "Individuals and interactions over processes and tools". So, start with making Dev and Ops working together closely, before jumping into advanced Continuous Delivery processes and tooling. And keep the end goal in mind, because DevOps will result in more throughput per sprint, faster feedback and higher quality products.