When we surveyed Agile teams, we found three Agile use cases that were each quite different.

1) Online services. These are providers of Web, SaaS, big data, and mobile services. They live in a competitive, rapidly evolving environment. They talk a lot about release frequency, testing, and automation, and much less about building permanent teams. They need to release quickly to avoid being crushed by competitors that release more frequently. We believe that most online service providers will move to continuous delivery and continuous Agile.

2) Long-cycle releases, every three, six, or twelve months. Leaders of these projects were happy with iterative or Scrum tactics. They talked a lot about building teams, which is an important focus of Scrum. If they move to continuous Agile, it is because their product is taking too long to test and release, or they want to increase the scale of development.

3) Service providers. These are consultants, outsourcers, design agencies, and corporate IT shops who have many clients to satisfy. Typically they have more projects than teams. Their concern was with prioritizing incoming requests, and with allocating resources. They frequently ask "who is available?" and they find it impractical to run a permanent Scrum team for each project. However, they can run short Agile release cycles with minimal rituals. We will show how to negotiate and deliver a continuous agile service project.

Embedded systems development is a fourth use case that we didn't cover in our survey. Many embedded systems developers use a "cadence" system where they put the parts together at fixed X-week intervals. Hardware changes are released infrequently, so this is almost the same as the long-cycle release case. However, I believe that the best embedded developers can unblock and accelerate by delivering new software builds daily. They can use "unveil" techniques to hide new software and hardware, until they are ready to be switched on in tandem.