Increasing Agility With Dynamic Code

In traditional project management, each feature is developed entirely within a development environment. And, each feature is only ever released to production once it is 100% complete, reviewed, polished, and approved. This has a negative impact on the quality of the feature; but, it also has a negative impact on the team itself.

Until a feature is released, it only represents a potential value for the customer. Which is a pleasant way of saying that the feature is entirely worthless until it is deployed to production.

This creates a challenging dynamic for the team because it means that the engineers on the team can only demonstrate value once the feature is completed and deployed. In such an environment, all interruptions come with real psychological discomfort: every time an engineer stops what they're doing, they see the finish-line—and their moment to shine—slipping further and further into the future.

And so, the team begins to view work as a competitive, zero-sum game. Cross-team collaboration—once viewed as an act of generosity—is now met with a residue of resentment. To protect itself, the team doubles-down on process and uses the existing roadmap as a shield that deflects all incoming requests. Soon, the team becomes so sclerotic—so unwilling to adapt—that even trivial product changes must be scheduled months in advance.

In order to fix this—in order to allow teams to be dynamic—we have to change the way in which engineers deliver value. Instead of delivering value once at the end of a complex feature, we need to let value to be delivered continually. This creates psychological safety for the engineers, who are then able to demonstrate value to the organization throughout most of the development process.

This psychological safety gives a team the freedom to adjust priorities on-the-fly. If something new comes up and it seems to be worth doing, the team can just stop and do it. Since the team has already been delivering value on the current project, there's no longer an overbearing pressure to take it to completion at this moment. Things can now get done when they need to get done (and no sooner).

This agility unlocks several psychological benefits. When a team is allowed to adjust priorities, it has a greater sense of autonomy. A lack of autonomy is the number one cause of burnout. Which means that engineers are much more likely to remain mentally healthy when they feel self-directed in some fashion.

Self-directed work is also endowed with a sense of service. When a team has the freedom to do work that they deem meaningful, the desire to do that work comes from a place of love and generosity—not from a place of obligation. This type of work is much more fulfilling; and acts to rejuvenate the mind, body, and spirit.

A dynamic team is also immunized against the sunk-cost fallacy. The sunk-cost fallacy is a phenomenon in which a team continues to invest time, effort, and resources into a project even when it would make more sense to move onto a different project.

When a project's value is only materialized at the end of the development process, abandoning the project prior to deployment feels like a failure. And, it makes all of the team's efforts heretofore seem like a waste of time. As such, in order to justify the work—and to prove to the organization that it wasn't a waste—the team continues to sink even more time, effort, and resources into completing the project.

If, however, the team is able to continually demonstrate value while developing a feature, switching priorities midstream no longer comes with a sense of failure. If the project delivered some value to the customer, the project was a success! And, moving onto something else isn't viewed as abandonment, merely an opportunity to create even more value elsewhere in the product.

And, of course, any incremental value that's already been delivered to the customer will continue to deliver value even after the team's priorities have changed. So, not only is this increased agility a win for the engineers in the eyes of the organization, it's also a win for the product in the eyes of the customer.

Building and delivering a feature incrementally also allows a team to work with the Goal Gradient, not against it. The Goal Gradient Effect states that people are most motivated at the start of a project and at the end; and, that they have difficulty maintaining that motivation during the majority middle. This is why long projects always feel like a slog no matter how exciting the outcome is bound to be.

By breaking a large project up into small, independently deployable tasks, we're essentially taking one giant goal and decomposing it into many smaller goals. Which means, at any point in the project timeline, an engineer is almost always starting off towards a new goal; or, getting close to completing the current goal. This sustains the engineer's motivation throughout the entire project; and, keeps the team operating with maximal enthusiasm.

Of course, none of this happens without feature flags. Until a team is able to operate using incremental releases, there can be no psychological safety or sense of self-direction. And, without these conditions—without a culture of trust and respect—each product team will eventually descend into a place of darkness where the only true motivation is that of self-preservation.

Have questions? Let's discuss this chapter: https://bennadel.com/go/4564