Starting up a DevOps team

Sometimes it seems like every company has adopted its own version of the Agile or DevOps way of working already. One would half expect the process of setting up a team would be straightforward. In my experience this is not the case, in the last couple of years I’ve supported several teams in either adopting elements of these processes or set them up. Though requirements differ between companies, I’ve worked out a general approach that works well for me, in this article I would like to share it. Hopefully, it will help you as well.

Process and backlog

The first focus is on stability and clarity for the team. To get this in place I get these in place:

• Either the iterations or a Kanban process, depending on the experience of the team and the project requirements. Generally, when going full DevOps with an experienced team I go for Kanban, otherwise, start with iterations so we have set moments to measure progress.
• Standup, refinement, and retrospective are key to progress. The form is not that important, but regularity is.
• Get the Product Owner fully on board, invest in mutual trust and work together to get the backlog up to speed. Define epics and features and enough user stories for the first couple of sprints. Invest time to get the stories functional, not too detailed but containing the information required.
• When doing initial negotiations, I make sure to reserve room for technical debt, generally around 20% of the time. Without some built-in way to deal with technical debt, it is a continuous battle to get time available.

A big stumbling block that tends to come up every now and then is how to unite budgets with agile planning. The easiest way I found to explain this is to do poker sessions on macro-level; estimate features relative to each other, take the smallest, estimate its time and then use that to estimate cost and regularly adjust. It will not give you the exact cost but gives as much security as detailed planning since those are generally also not accurate (only give a sense of security).

Repository

When the boundaries are set and the process is in place, the first thing on the agenda is to manage code repositories. To get it out of the way: it will always be Git, see below. Generally, an organization has some collaboration environment in place, otherwise, there are many online alternatives (Azure Devops, github, gitlab and others). Things to consider at this point are:

• Decisions on scope and naming convention of git repositories. It may seem early, but this discussion gets a lot of bias out in the open and gets the team aligned.
• Agreements on branching; when to create branches, how to work with them, conditions for merging. This is your day-to-day process and requires clarity in the team.
  • Feature branches per story is a very common approach and works well in most cases. I like the convention of starting with ‘feature/’ and deleting them after merge, since it keeps your tree clean.
  • When software deliveries are made to some other party (agile) or when different versions are ‘active’ (such as dev, test, acc, prod), tagging is vital. Generally working with release branches is needed to be able to do bug fixing/patches.
  • A very common thing I see is separate develop and master branch. In my experience, this generally offers more confusion and errors in cross-merging than it solves.
• Get pull requests agreements sorted. This is where your quality is checked, when this is not done right it can lead to decreasing trust from the Product Owner and make life difficult. Pull requests are the moment where you verify quality baseline, peer review, unit testing, code coverage and any quality tools you have in place.

More than once I got the question of why using Git is so important. Truth be told, other versioning systems (generally subversion and tfvc) support branching as well. The reason why is because the way branches are implemented. In Git you get the code in the context of one branch while others represent a branch as a directory on the file system. For this reason, automation is much easier to do with Git. Since automation is key to the success of agile and DevOps, it’s the logical choice.

Automation

At this point, the team can start writing code and to work on stories. My focus will now go to automation. I will look at:

• CI builds to continuously check the quality. At a minimum, it checks compilation and unit tests.
• Get as far as possible in the automated deployment. When software is only delivered to an external party, automate that delivery. Any manual step adds potential errors.
• Automated testing in the pipelines mentioned above. Any manual testing should be avoided. Of course, unit tests are all automated and part of the pipelines, and with all your options to automate integration tests there really is no excuse not to do it.
• Quality control, my latest favorite is sonarcloud and that level is basic. The next step is checking security vulnerabilities in code and in dependencies, dynamic security testing.

A great enabler is adding feature toggles, it helps you to deploy to production without the risk of breaking something, as you can manage whether that new feature is active on many criteria. Generally, it’s a consideration at the point where the first production releases are made, so I’ve not added it to the list above.

Organization

The previous sections were enablers for the team to get productive. Generally, though, the success of the team is dependent on collaboration with the organization. This means:

• Show what the team is doing, organize demo’s and make sure everyone is welcome.
• Managing backlogs across teams to align goals. Many organizations tend to struggle with this, and I’ve done several reorganizations in Azure DevOps to properly support this.
• Do quality, manage quality and expose quality. Develop trust, you need it to get the responsibility of managing the complete DevOps lifecycle.

Final thoughts

It may seem like a lot to do, know that for a new team in an organization that already does some form of agile it should take you up to two months to get everything in order. When converting an existing team to this way of working every topic mentioned above will have its own legacy/history, and it will take (significantly) longer. As long as you keep an open mind and open discussions, it will succeed in the end.