What codebase and CI/CD prerequisites enable LeSS feature teams?
Tests technical enablers for LeSS feature teams. Strong answers cover sub-10-minute CI, trunk-based development, comprehensive test automation, and decoupled architecture. Red flag: claiming coordination replaces shared ownership and continuous integration.
What's really being asked
Whether you recognize that organizational structure follows technical capability. LeSS feature teams are cross-functional and cross-component, so the codebase and pipeline must eliminate the friction that traditionally justifies component teams. Interviewers want to see you connect team topology to engineering practices rather than treating agile adoption as purely a process change.
The full answer
Four prerequisites in priority order. First, continuous integration that is actually continuous, meaning trunk-based development with sub-10-minute build and verify cycles so that multiple teams can integrate into main many times per day without chaos. Second, comprehensive test automation at unit, integration, and acceptance levels so that any team changing any component gets fast feedback on whether they broke something they do not own. Third, architecture and code health practices that reduce cross-component coupling, using evolutionary architecture, clean code, and possibly strangler fig patterns to break down monolithic component boundaries so teams do not need specialized gatekeeper knowledge to make changes. Fourth, shared code ownership mechanisms such as pair programming, mob programming, or collective code review backed by coding standards so that no individual or team becomes a bottleneck.
The mistakes people make
Suggesting that feature teams can succeed with better documentation, more coordination meetings, or interface contracts while keeping component silos. Proposing long-lived feature branches or GitFlow because teams are large, which destroys the integration rhythm that makes shared ownership possible. Claiming that each feature team should own a slice of the architecture, which misses the cross-component mandate. Ignoring the Definition of Done and suggesting that integration or hardening sprints can handle cross-team work.
What usually comes next
How would you migrate a component-team organization to feature teams without stopping delivery. What do you do when one component is a legacy monolith that only two engineers understand. How do you handle code review throughput when every team can touch every repo. What metrics would you watch to know if the technical prerequisites are actually working.
A concrete example
A telecom billing system has separate component teams for rating, invoicing, and taxation. To move to feature teams, they first collapse all repositories into a monorepo with trunk-based development and a CI pipeline that runs 4000 unit tests in under 8 minutes. They add contract tests between bounded contexts and use the strangler fig pattern to isolate the legacy taxation engine. After 6 months, any of the 5 feature teams can deliver an end-to-end pricing change because the architecture and pipeline removed the need for taxation specialists to approve every commit.
Interview question
Why must an organization establish sub-10-minute CI and decoupled architecture before adopting LeSS cross-component feature teams?
- a.To allow each feature team to own an independent slice of the architecture without cross-component changes
- b.To reduce the frequency of required coordination meetings between cross-functional teams
- c.To support long-lived feature branches that large teams need to avoid integration chaos
- d.To eliminate the technical friction that traditionally justifies component teams and specialized gatekeepersCorrect
Why? this is the answer
LeSS prerequisites exist to remove the technical friction that makes component teams and gatekeepers seem necessary, enabling any team to change any component. C is wrong because merely reducing coordination meetings does not eliminate the underlying dependency; the card explicitly warns that coordination cannot replace shared ownership and true continuous integration.
Just read this? Test yourself on what you have been reading.
Read the original → less.works
- #less
- #feature teams
- #continuous integration
- #agile
- #technical excellence
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles