In his latest book “The Infinite Game,” Simon Sinek, an inspirational speaker on leadership, empathy, and optimism, defines and contrasts leadership styles and their effectiveness based on the differences between playing finite and infinite games.
Briefly, a finite game is one that has a beginning, known players, fixed rules, and an agreed-upon objective that when reached will end the game. Anyone watching any sporting event or who has played any board game should be familiar with the concept of a finite game.
An infinite game is quite the opposite, played by known and unknown players, with no exact or agreed-upon rules, and as the title suggests, the game never ends. A football game itself is finite, but the football league is infinite. Players retire and new rookies are signed. Even new teams can be created. The league can change the rules and give the best draft picks to level out the playing field. And for the league, there are no winners or losers, the objective is to keep the entire game continuing.
Mr. Sinek posits that business itself is an infinite game, and that trying to play this infinite game with a finite point of view, focusing on endings and winners and losers, is to the detriment of the player and their specific business in the long run. With this understanding, I would offer that software development is also an infinite game that is traditionally misplayed with a finite mindset.
Software projects are acquired and managed as discrete events, but software products themselves live on in production with monitoring and operations. This is the disconnect that goes to the heart of and necessitates adopting a DevSecOps culture shift to everyone’s benefit.
A software operations group knows instinctively that they are playing an infinite game. The only end to operations, monitoring, security, and support is the end of the software product itself. There is no winning or losing in operations, just getting ahead, or falling behind. And success is about daily momentum and not about absolutes. The best operations teams follow an infinite mindset looking for ways to change the rules to their ongoing advantage. Instead of fearing surprises, they expect them and conduct post-mortem investigations to grow from them afterward. The most proactive teams strive for antifragile automation that benefits from introducing self-inflicted chaos with utilities like Netflix’s Simian Army or other tools for planned disaster scenario testing.
This is not the natural disposition of a software developer, especially a consultant following a waterfall management style. Organized as projects with release deadlines, software is about completing the job requirements on time and in budget. If you can manage that then you won, here’s a bottle of champaign and on to the next project.
Spending cycles automating deployment processes that the development team will only use once, or not at all, does not fit a single project’s objectives unless explicitly called out as a requirement for the project. Sadly, for some, even creating automated testing is a challenge and can be overlooked to meet deadlines. Countless overtime hours have been sacrificed by numerous employees to “win” a project deadline, which makes sense when playing a finite game. However, burning through assets to achieve a solitary goal may not make as much sense from an infinite game point of view.
This dynamic is more clearly apparent in grandiose waterfall projects but still can be prevalent with agile management just with shorter tickets and sprints. A never-ending series of finite games is still not an infinite game and thus has the same drawbacks when managed with a finite mindset. Evaluating software development only by completing tickets in timeframes that match the story point evaluation, or by enforcing steady burn-down charts, or by ever-increasing the team’s velocity is still finite game-oriented management.
All of which can lead to quicker burnout and is of no assistance to ongoing software operations. While there is clearly value in timely completing tickets, a broadening of a ticket’s Definition of Done (DoD) to include ongoing concerns yields better overall results.
As such, implementing Agile management partnered with a DevSecOps culture transforms the game and enables development to operate with an infinite mindset. That is to say when development focuses on the ongoing operational and security concerns of a new feature and not just on coding and testing the functionality itself, development starts playing their infinite game with an appropriately matching style.
With a DevSecOps approach, governance, security, and compliance are not afterthoughts, but rather an integral component to every task. Continuous Authorization to Operate (ATO) is the goal alongside generating a relevant value stream of enhancements. Managing this way means foregoing velocity for craftsmanship and honestly addressing technical debt reduction on every ticket. Consistency and smooth operational capabilities become the metrics by which we judge good development and not intensity of throughput for new task completion. Fortunately, the short-term velocity impacts are far outweighed by the benefits reaped in ongoing support and maintenance.
Simon Sinek goes on to delineate essential practices for adopting an infinite mindset in business management, all of which are valid and apply to a leadership level, however, there are additional considerations when applying this concept to transform software development. The necessary conceptual start to follow this paradigm is to realize that software development doesn’t end when the functionality is coded. Requirement definitions at the project and ticket levels need to reflect this transformation by including ongoing operational concerns beyond simply providing enhanced functionality. Managers and project leaders need to adjust story points and team velocity to account for these expanded requirements. And developer productivity metrics need to include aspects of operational results and end-user feedback.
As any operational person will declare, software projects will end, but software environments live on and must be continuously monitored, supported, and secured. Aligning development practices to the infinite game of software operations by following DevSecOps practices gets everyone playing the same game with the same style and yields the best results.
