For a tech team to be enabled they must be constrained. Steve Jobs said, ‘Deciding what not to do is as important as deciding what to do’. When he returned to Apple in 1997 to save them, his strategy was to produce only four products. A desktop and a portable device, both with consumer and professional models. He got rid of the plethora of other Apple products. You could say he constrained his team to enable them with focus and simplicity to develop those four products to perfection. Genius! We can find examples of enabling constraints all around us.

Sport is a composition of freedom and enabling constraints. The rules constrain what the athletes can do but enable the game. They enable interest in the sport. Who wants to play or watch a game without rules? They enable athletes to have strong and aesthetic bodies, sharp minds, health, coordination, balance, and so on. They enable spectators to be entertained and for jobs to be created (professional athletes, coaches, organisers, physiotherapists, etc.). All because people decide to play games that constrain what they can do. Players are free to be creative and express themselves within the rules. Tech teams should do the same. We should constrain ourselves such that we have enough freedom to be creative and innovative to enable our objectives. Let’s explore some options available to us.

Agile

Agile has excellent enabling constraints. Working in iterations constrains us from planning, analysing, and designing (in detail) too far ahead. But enables us to validate the assumptions we have at the beginning of a project with feedback produced by completed iterations. Agile says responding to change is more valuable than following a plan. If the feedback and data produced by completed iterations tell us that we won't be able to complete all the requirements in time, we'll have to compromise on the iron triangle (requirements, resources, or time). If we constrain the desire we have to execute our initial project plan perfectly, it enables project managers to respond to iteration feedback early enough. They'll then have enough time to 'turn the knobs' of the iron triangle to drive the project to the best possible outcome.

The daily standup enables a team to quickly assess their progress and give feedback to those in attendance. Constraining it to 15 minutes max enables dynamic and productive feedback. It’s a standup, not a sit-down, after all. Kanban boards can help us to visualise and maximise our flow of work. The WIP limits on columns constrain the number of stories that can be done in each at a time but enables us to identify bottlenecks and complete more stories. It’s better to complete 80% of the stories in an iteration than to complete 80% of all of them. Speaking of Agile, let's look at Extreme Programming (XP).

XP's Circle of Life

Extreme Programming’s Circle of Life depicts its practices. They are enabling constraints. Pair Programming constrains us from always coding alone but enables our developers to have context of each other's work and promotes collaboration. Test-Driven Development (TDD) constrain us such that tests must be written before the functionality. But they enable us to know if our code still works after we've changed it. Refactoring (a là the Campground rule) constrains us from just writing new code by requiring us to continuously make existing code (even if our peers wrote it) a little better. This enables our codebase to stay clean. Developers can be so tempted to use the latest library, tool, pattern, or architecture that they may use it for their problems, even if it leads to an over-engineered solution. Simple Design constrains this inclination to enable sophisticated solutions. A coding standard constrains us from coding however we want but enables developers to easily understand each others' code. Software is a marathon, not a sprint. Sustainable Pace constrains how often we work overtime to keep us productive.

Continuous Integration (CI), another practice from XP, became so popular that it’s now part of DevOps’ DNA. CI pipelines with quality gates (checks) prevent us from merging broken or not-up-to-standard code into the main branch. This enables us to automate the enforcement of many standards and to have a main branch that's always ready to be deployed to production. A stage that lints our code ensures our coding standard is adhered to, and a stage that runs our unit tests ensure they always pass. A Software Composition Analysis (SCA) stage constrains us from using vulnerable or dodgy open-source-license dependencies. This enables us to have more secure systems and mitigates intellectual-property concerns.

Social Thought

Who should choose enabling constraints? Tradition suggests the answer lies in a balance of subsidiarity and solidarity. Subsidiarity is a principle that says regulation should happen on the local level. By this principle, the local leaders of a team, such as team leaders and tech leads, have the authority to choose their enabling constraints. Solidarity is about the unity, alignment, and good of the whole. It motivates a central authority (such as the federal government in the USA) to regulate the entire organisation. A company's executives (or other high-ups) choose the enabling constraints in this view. Because a central authority isn't in the trenches, they may not know what the best solutions for local issues are. As a result, subsidiarity can be viewed as a constraint a central authority places on itself to enable those closest to problems the freedom to solve them. Even so, local teams should find a way to unite with the rest of the organisation. A balance of subsidiarity and solidarity is therefore needed.

Conclusion

We enable ourselves with constraints. How ironic! Sport. Agile. Kanban. DevOps. We observe it all around us. It takes discipline to play along, though, to agree to be constrained. Conscientiousness, the personality trait, is required for self-discipline. We should therefore strive to have proper enabling constraints and conscientious members if we want to be a high-performance team.