I don't think so but it is an interesting idea - do you have a reference?

Are you are of Prof Steven Alter's Work System Theory. It describes workarounds which might be similar to what you mean. Is that is the case then almost all business processes are agile in that workarounds spontaneously arise to deal with inflexible IT/IS systems.

For me, Business Process Management starts with an understanding of the "problem".  Why is the present task being performed? In my experience, as I have run discovery workshops to perform the task required through modelling, the team has almost never got to the end without making changes along the way.  For example, I was contracted to identify the cause of faulty product being delivered to a client's customers in a very specialised and professional industry. (Not IT.) Faults were not tolerable! As we modelled the "As-Is", the client's own staff easily recognised many of the causes of the faults (there were several) and immediately implemented changes to prevent future occurrences. The "As-Is" very rapidly became to "To-Be" as we worked right through all possible paths. So I am of the opinion that, at least in the way I do it, all BPM is actually ABPM! I hope that helps someone? As for Agile in general, I have always worked that way no matter what I do, so it's not surprising that I am comfortable to allow Agile methods to spontaneously occur within BPM.

If you mean by ABPM "an agile approach", this criteria is already supported by the iterative phases of any BPM lifecycle. You can see the lifecycles proposed in various research works (eg. Van der Aalst et al, Khoshafian, ISO 9000, etc.). However, if you mean "agile business processes" under the BPM, at this level different issues may arise.

Thanks Amina. The changes made in the case I described above proceeded both iteratively (we worked through all the logic three times, and some areas even more than that) but some of the most significant changes were made even as the initial model was recorded. That seemed pretty much inevitable, as the need for change was recognised immediately, so changes were made between discovery sessions.  But once we completed the first pass right through, we realised that we had to review what we had done to take account of further improvements that then became obvious. As far as I am concerned, that is the essence of Agile.

Thanks for your answers and input so far!

Yes, I'm thinking of an agile approach. In general, there are several references existing in the literature (I myself have published some too -> see my publications). Right now, I'm looking for some "real" practical experience. I'm interested to know where and how business processes are modeled/implemented with the help of agile methods already.

As I have been a self-funded researcher / developer for virtually all my career of more than 40 years and operating with insufficient capital, I have intuitively done almost everything in an agile way - iteratively and continually making improvements until the desired outcome was realised.  So when I started to focus on business process, this just seemed "natural".  I never assume anything or rule out any particular way to proceed.  I am often delighted to see the moment when my clients realise something and we change direction.  Peter, it is difficult to be more specific without knowing more about your requirements and reason for asking.  Maybe e-mail me direct? [email protected]