Brownfield

Agile software development has revolutionized the way private sector organizations build software. The primary tenets are that all companies are software companies, software is never done, and requirements always change. What does that mean for the federal space?

Organizations of all sizes fall victim to the wrong goal trap. Anywhere with more than 2 levels of management have intermediate layers with the goal of team growth or revenue increase at the expense of the larger system. Growing a DevOps team could lead to less efficient operations if they become an integral part to everyday operations. It would be better for them to be constrained and simply provide infrastructure and templates to the developers.

My favorite example of “rule beating” is the secure network that reduces usability to the point that people use hot spots and other mechanisms to complete their work. If you want developers to work, they need stackoverflow.

This is a pretty commonly used phrase so I won’t belabor the point, but it’s an important trap to be cognizant of when sharing resources. The most common solution to this problem appears to be “chargeback accounting” where ever mission and cost center has to justify their budget through revenue, even if it’s internal services.

The drift to low performance trap is incredibly pertinent to large enterprises and public sector organizations. In particular, system administrators and security practitioners appear to have many government programs held hostage by nightmarish controls and delays. “Everything takes a long time because [procurement, security, network, infrastructure, et cetera].”

Escalation or “Arms Race” is a feedback loop where increasing intensity is the only option for multiple participants in a system. The most obvious example of this is competitive exclusion, why just a few companies have the vast majority of government contracts. This anti-competitive behavior may be related to the drift to low performance.

Addiction in this sense is different from chemical dependence, though parallels are obvious. The idea here is that the system operates in a deteriorating baseline state for periods of time. After that state has created obvious problems, some external factor saves the day and fixes everything.

The original problem is never addressed, so it resurfaces later.

A policy like “use best practices in the pipeline” will result in a lot of jobs being disallowed. These bad practices are likely the first dozen baby steps toward better and eventually best practices.

GitLab’s developers use a pull workflow so the assigned field is editable by anyone. The intended worfklow is to leave the issue unassigned (though tagged for a team) and when a developer is ready, they assign it to themself and work on it. Assignment is seen as a “leave this alone if it’s not you” sort of signal rather than “someone wants me to get this done.”

Brownfield organizations typically have policies that were written under a very different development paradigm and create more problems than they solve under current Agile and DevOps practices.