Since the end of the 1990th, we see an ever growing interest in agile methods in software engineering. At the beginning of this movement, radical methods like Extreme Programming (XP) were proposed. Even though you might need a radical move to kick-start a revolution, it is usually not the radical approach winning the hearts of the many. Nowadays, Extreme Programming plays only a minor role in software development, but the methodology Scrum is very fashionable. But hey, what has a software development method like Scrum to do with business process management?
Well, there are many connections. For example, business processes get implemented as software and so you need a way to manage the belonging software implementation project. I call that "application of software engineering in business process management". But of course software engineering itself is a process and therefore a valid subject for business process management. I call that "business process management of software engineering". Finally, some people suggested using Scrum to manage BPM projects. I call that "buzzword bingo by some consultants in the BPM space" trying to get more attention by mixing their stuff with another fashionable topic :-)
Here at IDS Scheer, we use various development methods. Among them, different teams employ Scrum, which is one of the hottest topics nowadays in software engineering. Our new colleagues at Software AG also use Scrum in their projects and in the ARIS Community development team, we also use a flavour of Scrum.
I took up the challenge to document the Scrum process using BPMN 2. Attached to this post, you can find the first part of the result. I intended to create a single model documenting the whole process of Scrum. However, I soon noticed that the picture would get too complex to be useful. Therefore, I will show the details of the Sprint phase in a second post tomorrow.
Scrum defines three major roles, which are represented as lanes in my BPMN model:
- Scrum Master: He works as a mentor, helping all participants to implement the Scrum process. In terms of BPM, he would be part of the centre of BPM as a BPM evangelist and coach. The Scrum Master also helps to solve conflicts between involved parties, for example between the Team and the Product Owner.
- Team: This term is a curiosity, because one would expect that everyone working on a software project should be part of the team. In Scrum, the Team refers to the developers turning requirements into a shippable product.
- Product Owner: He manages the requirements collection (aka Product Backlog). He can add or remove requirements, change the priority and decide on the goals for a development cycle (aka Sprint).
My BPMN model of Scrum shows the main interaction of the different roles. If everyone follows the process and no problems arise, the Scrum Master is hardly needed. I modelled the different tasks of the Scrum Master as collapsed event sub-processes. Those sub-processes are only triggered if problems occur. Each event sub-process must begin with an event, which can be interrupting or non-interrupting.
The main action happens between Product Owner and Team. In most cases, both parties collaborate, but as it is impossible in BPMN to model that different parties work together on an activity, I assigned the activity to the party responsible for it. For example, the Product Owner defines the overall product goal during the Release Planning Meeting, but he needs the input of the Team to come up with meaningful estimates to base his release plan on.
The BPMN model of the Scrum process contains a loop. During each iteration, a new version of the product is implemented. An iteration is called Sprint. A lot of additional things happen during a Sprint. I will detail the Sprint phase in my second post tomorrow. After each Sprint, the Product Backlog and Release Burndown chart is updated.
In Scrum, everything happens within fixed time-boxes. For example, a Sprint should always have the same length. It is not allowed to extend the length of a Sprint to implement additional features. Instead, features are postponed to the next Sprint. Such time-boxes are also used for all other activities like meetings. The idea is to establish a rhythm everyone can breathe. It is the task of the Scrum Master to enforce this. I think the use of time-boxes is one of the major strengths of Scrum, because in software development it happens way too often that features for "an important client or prospect" are included delaying the release of the whole product. It also forces product managers to think in advance what is important. On the other hand, flexibility is maintained by Scrum, because Sprints should not be too long. In smaller projects, a Sprint is up to four weeks long, in larger projects not more than three months.
As we can see in my model, the Scrum process runs infinitely. It only terminates if no additional requirements must be implemented (this never happens in reality!) or if the product is abandoned.
So far, Scrum looks like an ordinary incremental software development process. However, we will see tomorrow that the Sprint phase is quite unique allowing a complete realignment of the product during each Sprint.
Note: Go to the second article describing the Scrum Sprint phase.
