The quick answer is yes. Although some lifecycles are depicted otherwise, the Scrum construction lifeycle of Figure 1 is a classic example of such, the reality on the ground is much different. Figure 2 depicts an agile, Scrum-based project lifecycle, adding an Ideation/Sprint 0 phase and a Deploy phase. Figure 3 goes one step further to present a full, agile solution lifecycle. Each of these lifecycles are described in The Scrum Lifecycles: Construction, Project, and Solution
Figure 1. The Scrum construction lifecycle (click to enlarge).
Figure 2. The agile project lifecycle (click to enlarge).
Figure 3. A detailed agile SDLC (click to enlarge).
Many agile purists will jump through semantic hoops to avoid using terms such as phase or serial, hence questionable terms like "sprint 0" or "hardening sprints", but in the end they're still talking about phases. On a Scrum project, sprint 0 occurs before any construction sprints, which in turn occur before any hardening sprints (sometimes called deployment or release sprints, there isn't a standard). In short, Scrum teams start with sprint 0, then construct a solution, then deploy the solution. Sounds a lot like phases to me.
Furthermore, the sprint 0 and hardening sprint(s) tend to be different lengths of time than construction sprints. Where a construction sprint tends to be 2 weeks in length "sprint 0" ranges between several days and several months (yikes) in practice, depending on the complexity faced and your capability to reach a common vision. Similarly deployment/release/hardening sprints tend to be variable length as well, depending on complexity, skill, and automation. So not really a sprint either.
Continuous delivery teams appear to follow a lifecycle that isn't phase based but that's simply because their construction phase lasts for many years, potentially decades. These teams still must have had some sort of concept phase back when the initiative was just an idea, an ideation phase to get going, they're currently in construction and likely production simultaneously, and eventually their solution may need to be decommissioned. So, once again, phases.
In the early days of agile many people were eager to completely break with the past. This break included abandoning existing terminology, even when that terminology was crystal clear. Doing so was a great marketing for anyone trying to sell you agile certification training or agile methodologies, but it made things confusing for practitioners. But it isn't the early days of agile any more, so we can choose to do better.
The bottom line is that agile teams work in phases. This is very clear for agile teams and not as immediately obvious for continuous delivery teams, but it still happens. And that's completely ok.
