Enabling Constraints
Software Engineer at heart. Tech Lead by craft. With 16+ years in software engineering, I solve complex problems and enable the delivery of a continuous and efficient flow of value.
An oxymoron is a figure of speech that pairs two opposing words. There is one I include in my software-engineering repertoire: enabling constraint. We can enable our goals by constraining ourselves. Let's consider this paradoxical effect.
Apple
Steve Jobs' strategy when he returned to Apple in 1997 (to save them) is an example of enabling-constraint thinking.
His strategy was to produce only four products: A desktop and a portable device with consumer and professional models. He got rid of the plethora of other Apple products. He constrained what Apple worked on to enable them to develop those four products, with focus and simplicity, to perfection.
I value his insight:
Deciding what not to do is as important as deciding what to do.
Think about it. Constraints are decisions of what not to do.
Process
Here's an enabling-constraint perspective on Agile process.
Iterations
Working in iterations constrains us from planning, analysing, and designing (in detail) too far ahead. That enables us to validate our assumptions early and continuously.
Initial-plan desires
Agile says responding to change is more valuable than following a plan. The feedback (data) from completed iterations may signal that the initial plan won't work.
If we constrain the desire we have to forge ahead with it, it enables us to respond well. We'll then have enough time to 'turn the knobs' of the iron triangle to drive the project to the best possible outcome.
Daily standup
The daily standup enables a team to assess their progress and give feedback to those in attendance. Constraining it to 15 minutes max enables dynamic and productive feedback.
Kanban boards
Kanban boards help us optimise our workflow. The WIP limits on columns constrain multitasking. That enables us to focus and resolve bugs quicker. As a result, we'll be able to complete more stories.
Extreme Programming (XP)
I love XP! It's my favourite Agile process. As a tech lead, I've relied on its practices to make our engineering productive.
XP's Circle of Life depicts these practices in a memorable way:
Pair Programming
Pair Programming constrains engineers from always coding alone. That promotes collaboration and enables them to have context of each other's work. It also bakes peer-reviewing into the coding process.
Test-Driven Development (TDD)
TDD constrains us from just writing production code. When doing it, we write unit tests first. That lets us know if our code works right after changing it. It also promotes more decoupled code.
Refactoring
Refactoring (a là the Campground rule) constrains us from just writing new code. We must continuously improve existing code (even if our peers wrote it). That enables our codebase to stay clean.
Simple Design
Most engineers seem inclined to over-engineer solutions. They do it just 'in case' it's needed in the future. Simple Design constrains this inclination to enable sophisticated solutions. It also reduces waste. YAGNI!
Coding Standard
A coding standard constrains us from coding however we want. That enables engineers to understand each others' code quickly. And reduce the cost of code changes.
Sustainable Pace
A software project is a marathon, not a sprint. Sustainable Pace constrains how often we work overtime. That prevents us from burning out.
Continuous Integration (CI)
CI pipelines with quality gates constrain us from merging broken or not-up-to-standard code into the main branch. That enables us to automate the enforcement of many standards. And have a trunk that's always ready to ship.
Small Releases
Small Releases constrains large-release (Waterfall) inclinations. That enables our customers to get early and continuous value. And us to get early and continuous feedback. Furthermore, it reduces the risk of deployments.
Customer Tests
Customer Tests are those tests included in the specifications of stories (also known as Acceptance Tests). It constrains developers from declaring a story as developed until all its acceptance tests have passed. That enables better flow by reducing bugs.
Whole Team
The practice where those working on a project co-locate (sit together). It constrains individual members from working wherever they like. That enables serendipitous and nonverbal communication.
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 team defines its enabling constraints.
Solidarity is about the unity and alignment of the whole. It motivates a central authority (such as the federal government in the USA) to regulate the entire organisation. By this principle, a central body chooses the enabling constraints.
Because a central authority isn't in the trenches, they may not know the best solutions for local problems. A balance of subsidiarity and solidarity is therefore needed.
Conclusion
We enable ourselves with constraints. How ironic! Strategy. Agile. Kanban. DevOps. You name it! Let's decide what not to do to enable what we want.
P.S.
This article has changed significantly since its initial publication on Apr 24, 2023.
