Technical Prerequisites for LeSS Feature Teams
Tests if you can link agile structure to technical architecture. A great answer covers codebase design for shared ownership, a fast CI pipeline for frequent integration, and a robust automated testing strategy.
What's really being asked
This question assesses your understanding of the tight coupling between organizational design and technical architecture. The interviewer wants to see if you can move beyond agile buzzwords and articulate the concrete engineering systems required to make feature teams successful. It specifically tests your ability to explain why practices like CI are not just 'good ideas' but non-negotiable prerequisites for enabling multiple teams to work on a shared codebase without constant blocking and integration hell.
The full answer
First, a codebase architecture that enables shared ownership. This often means a monorepo or a well-structured multi-repo setup with clear APIs. The key is that the architecture must be loosely coupled, allowing teams to work on different end-to-end features simultaneously with minimal merge conflicts. Clean code and defined interfaces are mandatory.
Second, a mature Continuous Integration (CI) pipeline. This is the most critical technical enabler. The pipeline must be fast, with a full build and test cycle completing in under 15 minutes, to encourage frequent commits and integration. It must be reliable, so a green build provides high confidence.
Third, a comprehensive and automated testing strategy. Since multiple teams are changing the same system, you need a safety net. This includes fast unit tests, broader integration tests, and end-to-end acceptance tests, often written using Specification by Example (SBE). This ensures that one team's feature work doesn't break the system for everyone else.
Fourth, a Continuous Delivery (CD) capability. The pipeline should allow any merged change that passes all tests to be automatically deployed to a production-like environment. This shortens feedback loops and reduces the risk associated with large, infrequent releases.
The mistakes people make
A major red flag is giving a generic definition of CI/CD without explicitly connecting it to the problem of feature teams, which is managing shared code ownership. Another weak answer focuses only on agile processes and ignores the technical architecture. Stating that every team member needs to know the whole system is incorrect; the LeSS framework specifies that the team as a whole has the required skills, not every individual. Finally, failing to mention the codebase itself is a significant omission; a tightly-coupled monolith will cripple feature teams regardless of the pipeline.
What usually comes next
How would you introduce these prerequisites into a legacy system that lacks them? What metrics would you track to measure the effectiveness of your feature teams and their technical environment (e.g., deployment frequency, lead time, change failure rate)? Describe a time you managed the transition from component to feature teams and the technical challenges you faced.
A concrete example
Imagine two feature teams. Team A is adding a new shipping option, and Team B is refactoring the checkout UI. Both features touch the same OrderService. With the right prerequisites, Team A can merge a change to the service, and the CI pipeline's automated test suite immediately verifies it didn't break the checkout flow for Team B. The entire build and integration test run takes 12 minutes. Because the feedback is fast and reliable, both teams can work in parallel on the same components without needing complex coordination meetings or long-lived feature branches, which is the entire point.
Interview question
When adopting LeSS, what is most critical for enabling multiple feature teams to work on a shared codebase without causing constant integration issues?
- a.Ensuring every developer is a full-stack expert on the entire system.
- b.A fast, reliable Continuous Integration pipeline for frequent code merging and testing.Correct
- c.Implementing daily cross-team stand-up meetings to coordinate dependencies.
- d.A fully automated Continuous Delivery pipeline to production for rapid releases.
Why? this is the answer
A fast CI pipeline is the core technical enabler that allows multiple teams' changes to be integrated and verified frequently, preventing 'integration hell'. While Continuous Delivery (D) is a valuable goal, it depends on having a solid CI process first.
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