A BPM view on Scrum
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.
My second post describing Scrum's Sprint phase is online now.
Hi, I was recommended to view this and I believe that it's a good thing that the scrum process is documented for teams combining ARIS with Scrum
I think you have caught the process well but I do miss out on two important aspects. First we have the difference between delivery and release. The principle for the sprint is that you create deployable software every sprint. This does not mean that you need to deliver this to the final product. For product companies this is an important principle but it is also essential for enterprise organizations. A big mis understanding about scrum is that you need to update the production environment every sprint and many Ops react to this, not thinking that they can do this. By differentiating between delivery and release you can clarify this. Of course, with agile values you would want to release every delivery, but this might not always be the case.
Also, you write that the scrum master is responsible for the communication. This is not necessarily true: the product owner is responsible for the communication with stakeholders. this is a group not identified in the process but can be seen as all not directly involved as team members, scrum master or product owner.
Another important aspect which perhaps is not caught by the process description is that the delivery of the sprint is business value. It does not have to be software. In most big projects, the first sprints might not result in so much factual software. Analysis, modeling, etc are also activities within scrum and they bring business value. It should therefore be clarified that the output not have to be software.
But yet again, wonderful initiative! Keep this up!
first, thank you very much for taking such a detailed look at my model. You are absolutely right that a release doesn't need to happen at the end of each Sprint phase, but that a product should be ready. I documented this fact in my model by including an exclusive gateway after the Sprint phase. One branch leads to a delivery and the second branch does nothing, because "no release intended".
Now I see that my description of the responsibilities of the Scrum Master might be unclear. Of course the Scrum Master is not responsible for communication, but for facilitating communication within the team. I think the role of the Scrum Master is hard to describe in a few words. He basically acts as some kind of coach within the Scrum project enabling everyone to work together.
It is very true that it is not the aim of Scrum to deliver software, but business value. In fact, this is what often happens in the first phases. For example, it is common that in the first Sprint only the overall product design and architecture is delivered. In my post, I focused on software only to make the Scrum concept easier to understand. But you are right, this is a simplification, which might not be very good.
Again, thank you very much for your input!
ah. I understood this as a not accepted delivery; a k a that the product owner does not think the delivery meets the requirements. But I'm quite new to the ARIS notation since I'm really a beginner
<offtopic> I love this kind of content discussions that goes beyond ARIS usage, and would love to see more of this here at ariscommunity </offtopic>
thank you, Roland. We're in the process of documenting our owen development process so this is a welcome discussion for me.
I am having some problems in opening or viewing your documents/models. Is there something I need to have installed?
Hi Sebastian . I have solved the problem.
I just now had a closer look at the diagram. I think the Sprint should be a call activity if we regard the process of your next related post as expanded Sprint sub-process. It may not be really reusable but having lanes could only be supported in that case.
I just posted a Scrum task board as ARIS Express model.
Hi Sebastion, just a question around Scrum. Lot's of scrum articles published on the web claims that the only tools you require are whiteboards and sticky notes. I'm of the opinion that models still play a big part in Agile / Scrum and would like to get your opinion on this as well? I fail to see how you can effectively maintain an implemented solution if no models exists i.e.
- process diagrams i.e. BPMN diagrams explaing the process definition
- supporting integration architectures i.e. Archimate actor cooperation models
- Logical data models i.e. IE data models and UML class models
- UML use cases etc.