If you have need for speed, a team that knows the space, and crucially a leader who can be trusted to depart from the usual process when that tradeoff better meets business needs, it can work really well. But also comes with increased risk.

General principle 2: create focus on the critical path. (If each ticket you work on is slightly different from other tickets and no cookie-cutter solutions exist, then there is some chain of slow, annoying, winding steps, and the rest of the dependency graph doesn't really matter, just these big pains in the butt that often are linked in the dependency graph only by the fact that it's going to be one developer working on all of them and they can't work on them all simultaneously. It follows that you can only get interesting speed improvements if multiple developers are working on the same change. Note that daily stand up is an example of a meeting which does not make a decision—it could but in practice nobody uses it that way—but instead its function is to create pressure on the critical path. Often unhealthy pressure, someone was sprinting at 100% and now they are getting a little burned out, and daily stand up forces them to do something that they can report at standup lest they be honest and say that they're suffering.)

General principle 3: process helps create shared reality. (Consider two different ways to protect prod from the developers. In one way, everyone commits to main, some file or database table or configmap contains a list of features, and those features can be toggled in dev, uat, or prod. The process here is, whenever you change anything, you wrap it in a feature toggle, so that your change does not impact prod if that toggle is off. Versus, consider having three different branches, you can usually commit new features to dev, eventually we cut a release from Dev and push it to the UAT branch, cut a release from UAT to push to the prod branch. But these are separate branches because we might need to hotfix UAT or Prod. The process here can go in these two different directions, see, but one of them leads to a shared reality, this is the entirety of the code and all of the different ways that it can be configured in our production environment, and we need to carefully consider how we remove those feature toggles—versus the other one has three independent realities and nobody is considering all of the different ways that it can be configured or what is being removed, and periodically you get bugs because people didn't revert the revert—what, you didn't know that you needed to revert the revert, you always need to revert the revert. So process tends to be more lightweight if it generates one shared reality).

General principle 4: process needs to help you figure out, and keep highlighted, the “Useless Without.” (There are many nice-to-haves, in a given project. There are a lot of them that people will say are must-haves. The product must be secure, the product must be available at this website address, okay fine. But there is one business goal that the project serves, which, if that business goal is not accomplished, the whole project is useless. That is the Useless Without feature. So I worked on a shop floor system of kiosks for like 6 months once before I determined from talking to the stakeholders that the thing was actually Useless Without time tracking, and this is a sensitive issue because unionized pipefitters are understandably skittish around surveillance technology that could be used in dystopian ways. But we're going to address their needs by looking at the project only, trying to figure out how long each of the steps in building the project takes, but we still don't talk about how we're trying to make the shop floor run efficiently. But you understand every meeting I had before we had clarified this, was actively detrimental to my productivity on this task.)