Agile Business Process Management - Part 2
Posted by Martin at Wieschollek December 22nd, 2009
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 address the issue in more detail.
The use of Scrum in BPM projects depends on several factors. One is the complexity of the processes and the goal of the project.
These different scenarios, I would like to explain below:
For all levels of complexity few precautions must be observed before one begins to execute processes in IT systems to implement:
- Strategy for the implementation process is available
- BPMS is a running system available
- Experienced professionals are available for process analysis
If these points are not met, you should create in upstream stages of the project these basics. It is advisable to implement a strategy to process to define. This describes how processes in the IT environment to be integrated, how the responsibilities are to be regulated for processes (process owner) and the methodologies, techniques and conventions to be used. By a good strategy could be implemented later processes quickly and flexibly. The strategy to grow only gradually with the individual-to-implement process often leads to the fact that the processes are not standardized, difficult to maintain and inflexible will. A unified strategy also reduces the necessary documentation required and thus reduces the learning curve of new employees. Since the essential elements of the various processes are identical and follow the same rules.
Scrum for processes with low complexity:
Scrum can be lived out here in its pure form completely. Especially when many processes should be implemented with low complexity to the process model with IT systems, this can be achieved with very good scrum. Process analysts refer to the model these processes with the customer and best with a standardized modeling notation (eg BPMN). Simple processes can be analyzed during the modeling process by experienced analysts to optimize the process flow for one, but also to determine the required resources, data and KPIs. The so-sculpted models can be implemented in a BPMS. Some of the existing commercial BPM suites offer the opportunity to build the modeled processes and implement the design process (implementation of the technical details that are required for process execution). Following the processes can be tested immediately by the customer in the BPMS. Processes of low complexity it enables all of these steps in a sprint (ie 4 weeks) to perform.
Scum on projects with moderate complexity:
Here it's getting harder to comply with the short iteration of the scrum. Scrum defines that after every Sprint is running a compatible product can be delivered. The processes are too large to model them during the sprint, analyze, design and implement one has in principle three possibilities:
- Processes reduce the divide /
- The sprint to extend
- The results of a sprint define different
To decompose 1) The process is not possible for all processes. Firstly, this approach does not support all BPM suites, and systems. For other processes deliver a specific result. With the intermediates, which can occur during a process, the Product Owner do anything. Thus this process of break down only if the process allows this at all. This is often the case when processes show many parallel branches. Then, these parallel branches are implemented gradually. A reduction of the processes could mean that the steps should be automated, or interfaces are mapped in a process in the first trial version of a manual task. This is obviously not possible in the processing of mass data, processes with high human interactivity already though. For example, users may need in the first version of data transferred manually in third-party systems and in the next sprint, the interfaces developed and automated. A major drawback of the process of decomposition / reduction is that the user must get used during the implementation process after each step in a slightly different process. This can lead to confusion and frustration.
To 2) A general extension of the sprints in a Scrum project is possible. So one can deviate from the usual 4 weeks and possibly define 6 or even 8 weeks as a sprint duration. Generally, this is not in the sense of Scrum. Due to longer sprints, much of the agility would be lost by Scrum. The Product Owner has to wait too long in certain situations to new demands can be realized. Therefore, the extension of the sprints with caution and should not exceed 8 weeks.
On 3) The third possibility is a combination of Kanban and Scrum. It is not implemented at the end of a sprint the final process, but there are for example required a total of three sprints. In the first sprint, the processes are modeled in the second Sprint to analyze the processes and 3 Sprint is in the design and implementation. This reduces the agility while back (the process itself is finished only after 3 sprints), but compared to the advantage of Sprint extension, which is every 4 weeks to provide results visible. The Product Owner may intervene every 4 weeks and possibly make new products to the Sprint Backlog with and can make the project better. Furthermore, this variant allows that instruct you in every sprint teams with different tasks. Thus, the modeling will be conducted by a team of analysts who possess any technical know-how of the processes to be modeled and are doing very well with the future users processes in workshops or interviews to collect. The next team analyzes and optimizes the processes and is specialized. The third team is specialized in implementing the necessary processes and development of interfaces. This can significantly increase the utilization of teams and avoid idle times of individual specialists. One sees here already but that one is also from the "classical" Scrum processes must deviate to medium complexity to realize.
Scrum for processes with high complexity
Processes with high complexity can possibly only with the above-described "Kanban and Scrum" combination deal. If this lengthy workshop process modeling and analysis to be necessary and are necessary for the introduction of major organizational changes already true Scrum experts need to work. This is probably a Scrum of Scrums is used to separate activities runterzubrechen and distributed to different teams. This again is important to ensure that the user stories are divided into meaningful parts packages that can be realized in a sprint. Nevertheless, the agile manifesto also be noted here. And it should be modeled as quickly as possible try to make processes run. Because followed a modeling and analysis phase, which lasts several months of a lengthy implementation frequently leads to failure of projects. It should also attempt to "start small grow big" approach to pursue. With the first trial version so you should not try to process 100% sure because with all the bells and whistles (interfaces, automation, etc.) to implement, but a meaningful reduction. For the last 10% are always the most expensive anyway.
Hello Mr. Wieschollek,
the link appears on the first article to be down ...
Best regards Martin Bartonitz
Hello Mr. Wieschollek,
I have still a few more ideas on how the stories could be cut for the iterations.
Incidentally, it is at scrum that the result should be "poteniell shippable". Ie, that users do not have to get after each iteration was new.
The cutting of the stories could take place in the rough after a) of the commentary you Praxishandbuch BPMN described method: Strategic Models -> Operational Models -> Technical models, and b) one process after another, and c) a piece of one process after another , which implies, however, that the process also permits.
What still remains open: if the process is then implemented, as it then continues with the process improvement cycle. Again, I can imagine that Scrum works. Only in longer cycles and total recurring tasks: First, the analysis, then the ideas developed to improve, then implement the improvements in the technical processes, and of course re-train the users.
What about the roles and BPM Scrum roles:
The CEO as the process owner?
The Process Manager as a Scrum Master?
Who sits in the Product Board?
Let us continue working on it necessarily here!
Hello Martin.
I see it very similar to Martin (Bartonitz): Not every release on Sprint-end will be delivered. It must be "just" run and theoretically Extraditables.
This provides a small difference but I think plenty of opportunities, tasks and content according to cut and pack in several sprints. That would happen in one way or the project because they organize their own work within the sprints must (at least the team or the staff).
Or do not you think? Oh yes and if the tool should not allow this practice, you probably have the wrong tool
) But seriously, this will then also in other places likely to be too rigid ...
Greetings!
Bernd
Hello Dr. Bartonitz,
to c) I can think of in connection with the camunda BPMN Framework, consider that the process not only can share "of length" (ie into various sub-processes), but could in some sprints and each individual involved in the process, since should be tried according to the framework so each involved a separate pool to pay. This would also reduce the complexity, there can be discussed separately after the capture of the strategic model, the operational model with each Prozessbeteiligtem (at least in large parts).
When Improvment Cycle I would not necessarily put in the long sprints. I would possibly moderate intervals usually perform mini-projects with Scrum. The first sprint would then deal with the analysis and evaluation of the collected information can then subsequently be given to whether it can be further optimized in the process sprints / or not. Another point is the "daily business" would, therefore, as the monitors of the process. Here I do not know exactly how you could use here specifically Scum. I think Scrum makes more sense in the project environment.
Very briefly to two sets of roles
I would rather use the process owner as Scrum Product Owner. As a Scrum Master an x-any employee, as this "only" the Scrum Papers monitored. What role then occupies the Scrum process analyst? Do we need another scrum roles? Quasi-one BPM add-on?
Greetings!
Martin Wieschollek
PS: Thanks for the note with the link. Is now corrected. But I see just that I also must customize the template, so my answer is right under your comment.
Hello Bernd,
this with the "run" you really should not take too seriously. I've heard of large corporations, where the management is working with Scrum. And at the level of any "executable" products are being developed, but strategies, concepts and visions. And probably also in several iterations. Corporate strategy is the one in my opinion, not in 4 weeks
Greetings!
Martin
Is repaired. Thank you!