We work in 4 to 6-week cycles, in small, self-sufficient teams, and have a couple of rules.
Instead, we're using 4 to 6-week cycles, followed by a 1-week cool-down. This allows us to focus on the things that truly matter, building good products, fast.
The cool-down cycle is used for design, development and testing, while the cool-down periods are used for client demos, scope hammering, POC or bug fixes, and change requests received from the clients after we showcase the work.
We work with small teams that focus on features and contain all the required knowledge in the team to implement that feature successfully.
Instead of dividing our departments into technology, we prefer to divide our staff into teams that have all the knowledge needed to implement a certain feature (all the layers involved – design, frontend, backend). This ensures a higher cohesion on the team and allows us to build better products, faster.
Smaller teams move faster, are more accountable, communicate better, and deliver better solutions.
Fast decision making
Flexibility
Improved communication
Reduce overhead ( core compecenties)
Increased accountability
Lower costs
Assigned to features, not tasks
Good technicians (developers, designers, testers) don't like meetings, and wasting time, they want to focus on the thing they are good at and to be able to hone their skills without other distractions.

The average developer spends a third of his time (roughly 11 hours/week) in meetings. Additionally, they spend around 6 hours in fragmented time (between meetings).
That means for a 40-hour week, they spend around 24 hours focusing on the tasks at hand (3 days/week instead of 5).
We prefer asynchronous communication by default and escalate to real-time only when necessary.
We've chosen to do better, we follow a set of rules that ensures our colleagues are working on the things that matter and they deliver better results, faster.