Technical Prerequisites for LeSS Feature Teams
This tests your grasp of the engineering practices that enable agile scaling. A great answer covers continuous integration for shared ownership, robust test automation, and a loosely coupled architecture. A red flag is focusing only on Scrum ceremonies.
What's really being asked
This question probes your senior-level understanding that agile frameworks like LeSS are not just process changes; they are enabled by, and dependent upon, specific technical disciplines. The interviewer wants to see if you can connect an organizational model (feature teams) to its required technical foundation (codebase and pipeline maturity). They are testing for depth beyond agile buzzwords.
The full answer
First, Continuous Integration (CI) as the most critical prerequisite. LeSS requires shared code ownership, where multiple teams work on the same components. CI, defined as a single main branch with automated builds and tests on every commit, is the mechanism that makes this possible without constant merge conflicts and integration failures. The feedback loop must be fast, ideally under 10 minutes.
Second, comprehensive Test Automation. CI is ineffective without a strong safety net. A good answer mentions a pyramid of tests: a wide base of unit tests (aiming for >80% coverage), a smaller layer of integration tests, and a few key end-to-end acceptance tests. This automated suite gives teams the confidence to refactor and modify code they didn't originally write.
Third, a Loosely Coupled Architecture. The codebase itself must be structured to support parallel work. This means well-defined module boundaries, clear APIs, and minimal hidden dependencies. Without this, any feature requires touching many tightly-coupled parts of the system, creating massive cross-team contention and defeating the purpose of feature teams.
Fourth, Clean Code and Shared Standards. With many hands in the same codebase, adherence to shared coding standards, clear naming conventions, and good documentation becomes non-negotiable. This reduces the cognitive load for engineers and makes the code approachable for the entire team.
The mistakes people make
Focusing on process instead of technology. Candidates who talk about sprint planning, retrospectives, or product backlogs are missing the point of this technical question.
Hand-waving about 'good CI/CD'. A senior answer includes specifics like single-trunk development, build-per-commit, test coverage targets, and fast feedback times.
Stating that every team member must know the entire system. The LeSS principles explicitly state this is a misunderstanding. The team as a whole possesses the skills, not every individual.
Failing to connect the practice to the principle. For example, saying 'you need CI' without explaining that it's to enable 'shared code ownership'.
What usually comes next
How would you introduce these practices to a legacy monolith with significant technical debt?
What specific metrics would you track to know if your technical practices are successfully supporting your feature teams?
Describe a time you had to resolve a technical conflict between two teams working on the same code. What was the root cause?
A concrete example
To enable feature teams, our first step was tackling the CI pipeline. Builds took 45 minutes and were flaky. We parallelized the test suite and set a hard 10-minute P95 build time target. We also enforced a 'no broken windows' policy: a broken main branch build was a stop-the-line event for all teams. This forced investment in test stability and made shared ownership practical, as the feedback loop became reliable and fast.
Interview question
Which technical prerequisite is most fundamental for enabling LeSS Feature Teams to successfully practice shared code ownership and parallel development without constant integration failures?
- a.Comprehensive test automation, including a wide base of unit tests
- b.Continuous Integration (CI) with a single main branch and automated builds/tests on every commitCorrect
- c.Strict adherence to Scrum ceremonies like sprint planning and retrospectives
- d.A loosely coupled architecture with well-defined module boundaries
Why? this is the answer
The card explicitly states that Continuous Integration (CI) is "the most critical prerequisite" and "the mechanism that makes this possible without constant merge conflicts and integration failures" for shared code ownership. While a loosely coupled architecture and comprehensive test automation are crucial technical enablers, CI is highlighted as the primary mechanism for managing shared codebases effectively.
Just read this? Test yourself on what you have been reading.
Read the original → less.works
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. Open roles that interview on agile — each one lists the topics its interview covers.
See open roles