Product type (Consumer/Enterprise/Specific vertical)
Product Lifecycle (where the product is in it's lifecycle and the competitive situation)
Technology (Mobile/Web/Systems)
Deployment Model (SaaS/On Premise)
The situation is constantly changing as the dimensions change, and therefore the approach that worked for your team few months ago, may not be the approach for going forward.
The combination of these dimensions will often dictate the Release Cadence. For example, you can organize the team for frequent delivery, but if the product is an on-premise solution, the customers may not want to absorb frequent releases. Mobile/SaaS world is different and there is an expectation for frequent delivery. If you add an enterprise aspect to the situation, then again, the frequent delivery may not be very welcomed even though the Mobile/SaaS nature of the product allows for it.
When we started the development of a v1.0, we had one big team of 12 people. When the team grew to over 20, we stayed in a one big team model, with the standup still taking under 15 minutes, which was really cool. However, the nature of the standup wasn't any more to coordinate the work, but merely to share the status, therefore losing it's real value. The functional teams were split by platform (mobile, web, server) in a service model, where the Server team would get a request for changes from the Mobile team. With the demand to deliver more frequent releases this stopped working and wouldn't scale, considering we wanted to keep the organization flat.
Because of the current competitive situation and considering how early the product is in the lifecycle, it was decided that frequent delivery model is to be followed even though the product is targeted for the Healthcare industry that doesn't absorb frequent changes well. With the pressure to deliver more frequent releases to the market we needed to reorganize.
The Product: Cloud based Mobile&Web app, Healthcare industry. v1.0 just 6 months ago.
The Idea: Cross-Functional Feature Teams + Parallel Releases
The approach we took was to assemble the cross functional teams around the next priority feature, the next feature and so on. Each team would have their own Feature Lead, responsible for the coordination of the work and making sure the design is getting done and documented etc. Think "Feature Team Scrum Master". With this approach the stand-ups make more sense: the people on the team are planning their project's work.
The next step is to lower amount of work in progress and amount of features in each release. This allows part of the team to work on the next release, eventually increasing the overall release cadence.
