Service architecture is the secret weapon that the big Silicon Valley firms are using to scale both systems, and teams.
Small projects are more efficient and easier to manage than big projects. We can make big software smaller by chopping it into pieces called "services." Services are separate processes, programs, servers, or business processes that have a defined interface. You can write tests to make sure that services respond the way you expect. As a system grows it will inevitably be divided into services.
Services are everywhere. If you make a Web application or Web site, you are providing services to a browser. And, you already have all of the problems with versioning services, because you are serving multiple types and versions of browsers. If you make mobile apps you are providing services to the mobile client. Installed software calls operating system services. Datacenter software calls database servers and storage and many other services.
It's difficult to release a big system reliably, with reversibility and low risk. It's much easier if you are releasing a smaller component or service. You can streamline the process of deploying it (or rolling back). You can rely on automated tests to qualify the service for release, because it has a defined interface that you can test.
Here are some strategies to get started with services that you can release more frequently or continuously:
1) Wrap old code into services. Define an API or an interface to the old software, and write automated tests to make sure that it works the way you expect.
2) Put either client apps, or backend apps, on a faster release schedule.
3) Package new features into services.
Some systems have hundreds or thousands of services running. They scale their organization by assigning each service to a team that is responsible for as much as possible about the design, development, testing, and operation of that service. It's really hard to design an organization to build and operate and support hundreds of different pieces of software. It's easy to assign those things to one team, and then add teams as needed.
Find a Tech Lead to take responsibility for a service. This eliminates project management layers.
You can build a team around a tech lead. You do not need a complete cross-functional team to begin with. The team can be any appropriate size, with the tech lead qualifying new contributors, making sure that code review and quality control is good, and answering questions. A practical team size is three people - the smallest size that accommodates vacations. You can rotate in new leads after they have some experience on the team.
Service leads will collaborate in real time with tech leads delivering end to end stories and features. Service leads should review and accept changes from the contributors that are delivering complete stories.
Tech leads release service changes as soon as they are ready. This process should be fast and responsive.
You will need to change your services over time, adding and removing interface components. However, you need to stay compatible with all of the clients that use the services. There are two approaches.
The "centralized" approach makes changes in all of the clients, at the same time that you change the service interface. To make this work, you will need a continuous integration system that tests the complete system with all clients, and finds any mismatches as early as possible. So, it is closely related to the centralized continuous delivery method.
The "distributed" approach uses services that are backwards compatible. You make new versions of the interface, but you keep the old versions, and you keep running the tests for the (recently expired) old versions. You will need this approach if you have components that are installed over time (e.g. browser and phone clients) or maintained by separated teams and partners and vendors with separated test systems.