Brownfield software and organizations are often in the process of trying to embrace agile ways of working. There are several flavors of agile which focus on group dynamics and optimizing time spent for a given period of time. The themes include:

1. short cycle times [2-week sprints]
2. flexible requirements [backlog rather than waterfall/Gantt]
3. daily stand-up meetings [15 minutes or less]
4. product owners with autonomy [can prioritize features]

The outcome of these is actually problematic in a lot of cases:

1. nothing gets done
2. no documentation
3. lots of disruptions
4. concensus building is impossible

So a set of approaches to make agile palatable for larger organizations emerged such as Scaled Agile Framework (SAFe). Adding a set of waterfall-style constraints to a team struggling to become more Agile is a great way to keep them waterfall but with agile-named meetings.

Why GitLab?

Note: Despite leaving GitLab, the below is all still entirely true. Coder doesn’t have much to do with planning so this is getting left alone.

GitLab containing the Epics, Issues, Milestones (sprints), and Code in one place makes it easy for people to see what is going on. The magical ingredient is the Merge Request which is how code moves from a feature branch into the master branch (assuming GitLab Flow). The Merge Request is an automatic PM going around to every developer and asking them, “how’s it going?”.

Once the scrum master and product manager has instant visibility into all of the work going on at a given time, they are empowered to make resource decisions, feature decisions, and intervene or collaborate to escalate or avoid a problematic implementation. The combination of code changes, review apps, and pipeline status in the merge request gives oversight teams visibility into how things are actually going, rather than “green until the day before release and then suddenly red”.

Agile Practices

While the afforemntioned way of being agile works fine for greenfield and learning organizations, many existing orgs struggle to find the right balance between velocity and compliance. Many older organizations have transition-to-ops flows that require change review boards or IV&V. A lot of these are built into the procurement process and would require a contract modification to change at this point.

1. Branch strategy (and tags, and other git stuff)

The first thing to tackle for making a project more agile is to have the work being done in a way that can be measured and evaluated. Starting with a git workflow that is as simple as possible makes the measurement easier to do. GitLab can enable a lot of patterns here, but the best one to shoot for is the GitLab Flow pattern. The master is the “default” branch, it’s protected from anyone but the maintainer touching it. The developers (employees or contractors) create a branch for the feature they want to build (using the Merge Request view) and collaborate there. Multiple developers can share a feature branch because the Merge Request object helps them coordinate.

For the release side of the branch strategy, again GitLab’s interface for exploring branches and tags enables a variety of strategies. The recommendation remains (fewest branches) so having releases exist as git tags typically works better.

2. Groups and Project Heirarchy

As mentioned in the BrownField DevOps page under 5. Dependencies, using GitLab groups to clump and split work helps to create loosely coupled and more interopable relationships. One of the core focal points of this project is to use the GitLab heirarchy and cross-project coordination patterns to enable brownfield monoliths and SOA systems to naturally become transformed.

The idea is that with specific constraints and accelerators in place, developers will find that the easiest thing to do in a given situation happens to align with loose coupling and microservice decomposition. The two mechanisms enlisted to enable this are:

1. Developers naturally wanting to go faster
2. Writing code is easier than reading code

3. Status From Data, Not Opinions

GitLab has only two statuses for an issue: Open and Closed.

At first glance, this looks like an unsupportable workflow due to the lack of granularity. Jira and other tools allow hundreds of statuses and add layers of automation and required field rules in order to make those statuses make sense.

GitLab’s approach is to link the issue to Merge Requests, which are then linked to code changes and pipelines. Any issue that is “open”, you can see if MRs exist, if they do, if they’ve been contributed to, and if they’ve been contributed to, are the builds and test passing? Those values come from the real interactions and output of the team rather than a field that someone decided to fill with some data.