MFT Energy Case Study Challenges 'Chaos' Myth, Thrives with Pure Trunk-Based Development

A recent case study from MFT Energy, an energy trading company, provides compelling evidence that pure Trunk-Based Development (TBD) can lead to exceptional software delivery outcomes, even under challenging circumstances. Dispelling the common fear that committing directly to the main branch leads to chaos, MFT Energy’s new team, working in a new domain with critical deadlines, thrived by adopting what they termed ‘main as default trunk-based development’ (MAD TBD). Their approach involved committing straight to main, leveraging a pipeline for automated build, test, and deployment to a test environment, with developers able to deploy to production upon successful validation. Notably, this success was achieved without mandatory pair programming, strict Test-Driven Development (TDD), pull request gates, or rigid review processes. The team focused on small increments (90% of 2,500 commits were under 200 lines), feature toggles, and fast feedback. Survey results were overwhelmingly positive: every team member strongly disagreed that ‘Main is often broken,’ with an average score of 9 out of 10 for ‘Main is continually in a deployable state.’ Service quality scored 8.5/10, and DORA metrics—low change lead time, high deployment frequency, low change failure rate, and low mean time to recovery—were all excellent. This outcome was attributed to three core engineering principles: small batches reducing risk, fast feedback hardening the system, and low transaction costs encouraging good behavior and rapid flow.

While TBD proved highly successful, their non-blocking code review approach garnered only a 6/10 average score and a negative Net Promoter Score (NPS) of -7. Issues arose from a lack of prioritization, reviews being interpreted as non-urgent, leading to stale feedback, and a perceived lack of value. Critically, the team reported no shared purpose for the code reviews, hindering consistent value and effectiveness. This suggests a need for clearer objectives and more real-time collaboration, such as pairing or mob programming, to complement non-blocking reviews. Despite this, the team overwhelmingly preferred TBD, scoring it 7.6/10 overall with an NPS of 33, and an impressive 8.5/10 when asked if they would continue using it on future projects. The case study underscores that TBD is not inherently dangerous—large batches are—and that small, frequently validated increments are key to robust systems. It also highlights that TBD can be adopted by most teams sooner than they think, without extensive prerequisites like perfect unit test coverage or mandatory TDD, by focusing on organizing work in small batches, applying feature toggles, adopting safe incremental design, and gathering fast feedback.