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.
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
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
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.