After the third workshop on Agile BPM there are new questions for which we must find an answer. First, we have expanded our focus. We now consider not only scrum. We will now examine some aspects of agility for their applicability in BPM projects.

The thesis that the agile techniques, process models, principles and approaches to faith in BPM projects have an advantage ablative methods is still a classic. Especially in the spot speed and flexibility supports the "agility" while successfully implement BPM projects.

In order to test this hypothesis we have (friend of camunda Jacob, Christian Weiss of oose, Martin and I Bartonitz of Saperion Seven Principles) are based on the structures, the Christian in his video showing more concerned with the issue. Here we have once again found that the projects on BPM can be very very different. Even if we commit ourselves to a very simple IT-based process. Today's technologies are based on a still very intensive programming implementation (eg jBPM) to the zero-code "development" (eg Intalio or inubit). These differences are reflected in the consideration which naturally agile components can be put to good use again.

The interesting questions for me to date are:

• How do I deal with iterations in the zero-coding BPMS?
• What should I look at the various iterations when interfaces are involved?
  • This interface and an enterprise service bus contracts make sense?
• Is it possibly make sense in the BPM 2.0 prototyping approach apply?
• What should I look out for when I'm in my iterations of a high degree of dependence on "external systems"? (Eg if you also need interfaces, consume you want, but to access, complete the bz only conditional influence)
• How can you break down projects make sense? If my process still needs to be developed as a GUI, then the GUI development is yet again a classic theme in the development of BPM project
• How to deal with change requests in the BPM project? Especially if these CRs have a significant influence on the process flow.

In all this mind, I find myself once again very close to IT projects. But it is always important to mention that IT's share is in BPM projects often only 20% of the overall project.

As in the article " Kick-Off: BPM + Scrum "published on the James Friend bpm guide.de we wanted to examples of different" patterns "bring. A sprint in Scrum is to last between 1 and a maximum of 4 weeks. Therefore, it may be necessary to divide a process into smaller units to these units work in the sprints to. As the result of a sprint a "shippable executable product" should be, must be divided so large processes that these sub-processes can be useful and rolled out as independently as possible. Following my example of the dismantling of processes with multiple parallel process trains. (more ...)

Because I just happened to come from a PRINCE2 training and now my shoulder hurts from carrying books I've come to this slightly different methods of comparison between Scrum and PRINCE2.

(More ...)

Agile project management is indeed the time, especially in IT-projects totally hip. More and more companies are interested in Scrum, XP and Co. fail because many projects are carried out according to conventional PM methods. The reasons are often the complexity of projects and poor communication.

The same problems I am also aware of BPM projects. It loses itself in process modeling, analysis and design in detail. These phases often take several months. The processes are designed according to the analysis are no longer at the beginning of the current design, but after yet implemented in any system. In effect, the processes are not fit to the already long been a changed real business.

Works best in this environment, an agile approach?

(More ...)