I have a SOA view of the software development lifecycle.  And, in that SOA view, BPM fits nicely.

First, a comparison: Waterfall looks like this:
Waterfall: Plan –> Envision –> Design –> Develop & Test –> Deploy
Agile: Plan –> Sprint –> Sprint –> (occasionally) Deploy –> Sprint –> Deploy

A SOA SDLC looks more like this:

Plan –> Sprint (Process and User Experience) –> Sprint (Process & Services) –> Deploy –> Sprint (P&UX) –> Sprint (P&S) –> Deploy

In other words, you get as far as you can go with the user experience, you update the services, and you deploy.  Then, you do it again.  (I think Agile works a LOT better than waterfall).

So what does a “Sprint (Process and User Experience)” do?  The dev team is focused ONLY on the front end.  No changes to the back end are allowed.  This is a feedback cycle, in that services are developed slowly and carefully, mostly with heavy unit test and runtime testing requirements.  During that time, there is less involvement with the customer’s team.  So by cycling like this (assuming sprint length of between three weeks and five weeks), you can have greater feedback and user acceptance testing by consuming more of their time in U/X during ‘high cycles’ and let them do their ‘day jobs’ during service cycles. 

During “Sprint (Process and Service)” cycles, the team focuses on meeting the string requirements for creating and consuming enterprise services.  Heavy unit tests.  Real-time test harnesses.  Synthetic Transactions.  Idempotent design.  Activity Monitoring.  Performance testing.  Reliability testing.  You get the picture.

Both kinds of sprints: process changes are happening.  That is because it can take a LONG time to run through a User Acceptance test on a Process, get feedback, and incorporate it.  No good reason to create a ‘low cycle’ in that work.

I’m assuming mature process management tools, of course.