A few weeks ago I wrote a blog about an integrated agile/DevOps approach, which I called BusDevOps (Agile & DevOps, why not BusDevOps?). The question of how to start often comes up. So, let me try answering it here.

In that blog I suggested that the best results are obtained when combining agile and DevOps capabilities, where the ultimate goal is to have the whole development/deployment process improved and automated. There are two ways to do this:

1. Function by function, (for example, starting with the actual software development, then testing, and so on

2. Working with teams and projects.

The advantage of the first approach is that we move all involved teams at once, the disadvantage is that we have to cope with the ones not interested in moving. As resistance to change is often rather high in organizations this may not be the best approach.

The advantage of the second approach is that you can build on the enthusiasm of teams and use that enthusiasm to convince the remainder of the organization. I prefer the second approach despite the fact that it forces the organization to work with two approaches for a period of time. But frankly, if you have applications that are close to retiring, you’re probably not interested in changing the way they are operated, maintained and enhanced. So you will end-up with different approaches anyway.

Choose the right teams

Start with one or two projects. Which projects? Choose projects with a certain visibility in the organization, but not under strict timelines. Indeed, the initial move to BusDevOps and the associated learning curve may generate some delays in the projects. You do not want the move to be at the detriment of the business or you may kill the reputation of your new approach.

Assess the willingness of the teams to try something new. If you get pushback, try another project. What you want are individuals ready to go the extra mile to ensure success. And you will need that success to demonstrate the feasibility and convince others to join.

As I mentioned, start small. Nominate one or two teams to get going. You want a manageable group to start with. Get them trained on agile principles, using the SAFe framework for example. This will give them a basic understanding of what they’re in for.

Prepare the environment

You will want the team to have a supporting IT environment in which they can work. That’s the DevOps environment described previously. Quietly set such an environment up. Make some choices as to which tools upon which you want to standardize. Do not go overboard on Day One. Start with just a source code repository, an artefact repository, a continuous integration environment, and an automated deployment environment. You’ll be able to add more tools when you understand how the teams will work and what their exact requirements will be.

The human side: Set-up a workshop for them to experience.

When our own IT department moved to BusDevOps, they started with a one-week workshop during which the teams experienced working in the new approach. Supported by some external experts, they combined actual working with discussion sessions to gain a consensus on how they will work, what is important to them and how to communicate their learnings.

I suggest you do the same. Have the team(s) in one room, experiencing what it means to work in sprints, and to cross organizational boundaries. Have the developers spend time with the testers and the operations people so they learn to understand where they come from; what helps and hinders them.

Give them access to the tooling you set-up so they can start using it. Have them document their findings during the week. You may actually want them to develop a manifesto highlighting the key practices they want to take forward. Have everyone sign it at the end of the workshop.

Now you have teams that have experienced the new way of working. This does not mean they’re experts, but they can go back to their regular work and perform it in the new way. The tools are in place, the teams are motivated.

Start the real-life experience

Keep the experts at hand. You may not need them full time anymore, but have them coming by regularly so the teams can ask them for help when they get stuck. Keep it that way for two to three sprint cycles, including at least one deployment to production. This will give the teams the feeling they are supported throughout the process. The first few sprints will probably be slightly longer than the norm (typically every other week). That is not an issue, the teams need to find their marks. Make sure that once a sprint is successfully accomplished, you celebrate that success.

Ultimately, you are building awareness for the new way of working and to motivate others to join the new approach. Depict the new approach as being fun and interesting. You want additional recruits to increase the amount of teams that are following a BusDevOps approach.

The automation side: Continuous Integration vs. Continuous Deployment

We’ve been talking about the human side of things, but there is also an automation side. Where do we start here? In parallel with the workshop, start looking at the automation. Maybe you’re already doing something. If not, you may want to look at Continuous Integration first. This implies the automation of most of the testing. Have your test engineers think through how they could automate some of the tests they already do. Have them think through that while they are in the workshop. Make sure they get help for choosing tools and methods to automate testing.

Ultimately what you may want to do is to change the way developers operate. When they have to develop some new functionality, have them first describe how this functionality should be tested. Their colleague responsible for testing will then automate the test procedures while they develop the software. As soon as a first version is out, it can be tested. The benefit is that the developer knows much quicker if something goes wrong. This ultimately benefits the developers as it increases their productivity.

Once that is done, start working on continuous deployment by including a couple operations people on the teams. Have them describe what they have to do in the deployment process and which difficulties they face. Initiate an open debate. It is not about who to blame but about how things can be improved. Once an initial understanding is created, get the operations people working on automation of the deployment. Use a topology-based approach where specific deployments can be identified for middleware and database deployments. Re-using the same topologies for these components leads to consistent installations and facilitates operations. This however implies that governance is put in place early on to define what installation approaches are taken. In case a developer requires a different installation they should go through the governance process to gain approval. The benefit here is consistency and ease in operations.

The best of both worlds: Traditional and BusDevOps in parallel

For the foreseeable future you will run traditional development cycles and BusDevOps in parallel. The objective is to use communication, awareness building and celebration to increase the amount of projects (and therefore teams) that are performed using a BusDevOps approach. However, you’ll have some applications that are not changing often. It may not make sense for those applications to migrate to a BusDevOps approach. Move the people that are resistant to change to those applications so they can continue doing what they are familiar with.

Most of your employees will have the opportunity to follow a new approach, learning something along the way and gaining new skills. The enterprise in turn will gain agility and be able to respond faster to changing demands of the business. Isn’t that the best of both worlds?

The original version of this blogpost was released in early 2016 on the CloudSource blog. As this blog has been closed during the splitt of the HPE company, I am in the process of republishing the key articles on the current blog.