Introduction
Process agility cannot rescue a codebase that fights every change. The teams that deliver reliably sprint after sprint have invested in the technical practices that make software safe to change — automated tests, trunk-based development, continuous integration, refactoring as a daily habit. Without those, "Agile" becomes a series of broken delivery promises followed by ever-longer hardening sprints.
Technical practices are the engineering disciplines that make iteration sustainable. They are not the visible part of Agile — they are the substrate that makes the visible part possible. The team that does sprint planning beautifully but cannot safely change a 10-year-old module will eventually become a team that ships less and less, no matter how clean its retros are.
Topics
Test-Driven Development (TDD)
Writing the failing test first to drive the design of the code that satisfies it. Red, green, refactor.
Read →Behavior-Driven Development (BDD)
Given-When-Then scenarios as executable specifications that bridge the conversation between business and engineering.
Read →Trunk-Based Development
Short-lived branches merged into a single trunk multiple times a day, with feature toggles hiding incomplete work.
Read →Feature Toggles
Runtime switches that let teams merge incomplete or experimental code without exposing it — deploy is not release.
Read →Feature Branching vs. Trunk-Based
The long-branch model (GitFlow, etc.) and its trade-offs against the short-lived branches that continuous integration prefers.
Read →Pair & Mob Programming
Two developers at one keyboard (pair), or the whole team at one (mob). Slower individually, often faster as a system.
Read →Shift Left Testing
Moving testing earlier in the lifecycle — into design, into pull requests, into the developer's local loop — rather than gating at the end.
Read →Test Automation Pyramid
Mike Cohn's model: many fast unit tests, fewer integration tests, fewer still slow end-to-end tests. Shape matters more than count.
Read →Exploratory Testing
Skilled, intent-driven testing that finds what automated scripts cannot — the unknown unknowns of how the system actually behaves.
Read →Technical Debt Tracking
Making the cost of shortcuts visible, so the team can decide deliberately when to take them and when to pay them down.
Read →The Practices Compound
None of these practices stand alone. TDD without refactoring produces brittle test suites that lock in bad design. Continuous integration without automated tests is just frequent breakage. Feature toggles without discipline produce a codebase full of dead switches no one dares remove. Each practice earns its keep through the others.
Start where the pain is loudest. If releases are scary, invest in CI and trunk-based development. If changes break old features, invest in automated tests at the right layer. If estimates are wildly off, the problem may be untested code rather than poor estimation. Technical practices are how teams stop paying interest on past decisions and start compounding the value of new work.
Back to Hubs