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

I have frequent experience with a very long projects on Business Process Management made. Mainly through the cooperation of many departments in an end-to-end process is a process increasingly larger and more heavily-overdue project. Although many activities in the process often been fully clarified and may have even been developed already completed the process can not be imported because somewhere a little more activity will be coordinated. With an agile approach would allow all activities to be implemented more quickly and clear the desired result could be adjusted more quickly. Therefore, the issue of Scrum is very interesting, but not easy. Scrum was originally designed for software development and not for BPM projects. My first thoughts on this combination, I have already described in the blog (see Part 1 and Part 2 ). The same ideas have also Dr. Martin Bartonitz of Saperion and friend Jacob made ​​from camunda. For us to discuss and share the combination BPM Scrum and we held a small workshop with James in Berlin. The results of our first workshops are on bpm guide.de and looked up in the forum of the BPM network are discussed. I'm looking forward to the feedback in the forum.

In the first part of the topic Agile Business Process Management , I wrote my first thoughts on how to analyze processes modeled using Scrum. In the second part, I would like to more closely address the issue.

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