Scrum is a software implementation methodology within a software development project that puts a special focus on the effectiveness of the implementation and therefore suggests a strictly feature-oriented development.
I explained the reasons behind this in my article “Effectiveness instead of Efficiency: The Scrum Compromise”. And a project should have strong incentives to use this methodology over another because it is not always the best methodology one could use.
It is not enough for me to describe how the artefacts (roles, Sprints, daily scrum, etc.) are implemented and how they should be applied, as is often the case in the relevant literature.
At first it is important to understand why they exist and why they are necessary to be successful.
You will then doubly consider if you can ‘customize’ some things now or then, or if you will be able to estimate if this is meaningful or possible at all and what impact you can expect.
To keep things short, to the point, and entertaining, I designed the model of the 4 Cs.
Don’t worry, this is still pure Scrum and not my personal version. It’s just a way of presenting Scrum and I hope you find it as plausible as it is logical.
The first two C’s stand for Commitment and Completion.
They form the static columns, the paradigm on which Scrum is based.
The other two C’s stand for Communication and Common Sense.
Common sense – yes, you did read correctly. Using common sense is half the battle! communication and common sense are the dynamic components and describe how Scrum is implemented. Two basic values and two techniques, that’s all it takes.
In short:
If we set the commitment to values and the completion as the highest goal in a software development project and then use common sense and a specific way of communication, then we automatically arrive at the Scrum methodology with all its artefacts, processes, etc. Why don’t you give it a try?
If it is important to me in my project to get a clear commitment, then it would be reasonable to let the development effort be determined by those who do the development – for example. And they will have to decide for themselves how to implement the requirements.
This is how self-determined Scrum teams are created.
Of course, it makes the most sense to limit these commitments to units that are as small as possible and can be easily managed by a team. So it’ s better to do short Sprints, each preceded by refinement and planning, to create that commitment.
Then we want to make sure that the commitment is maintained during a Sprint.
Daily scrums are not about teams saying good morning or creating a feeling of unity or telling each other what they did yesterday or what they will do today. That may happen, but it’s not the purpose.
The purpose is to renew the commitment given at the beginning of the Sprint daily.
Are we still on track or are we in danger of delays? And if so, how do we get back on track and ensure commitment?
Sprint burndown charts are useful for a project manager to track this. And, of course, I need a facilitator for this process. Let’s call him a Scrum Master.
He is not responsible for making sure the team is process compliant. He does that, but that’s not the purpose. Working in a process-compliant manner is not an end in itself.
The purpose is to keep the team capable of work and commitment.
Because the commitment was given on the premise that the resources are available for the Sprint and are not disturbed and these can work without disturbance from external influences.
So we can see that almost all roles and organizational or administrative artifacts can be derived directly from the commitment paradigm.
So if you want to customize anything in your methodology, first ask yourself if the team will still be able to commit.
This is particularly true for all those cases where resources are temporarily withdrawn
from a Sprint, usually for unscheduled workshops, bug fixes, presentations,
maintenance, etc.
Undoubtedly, scope changes halfway through a Sprint are the biggest enemy of commitment, as they disrupt the Sprint’s elaborately planned balance.
It is also important that a commitment is not only kept but can also be verified.
It would be reasonable to finish something so that I can verify it. The purpose is to keep the team working and able to commit.
From my project management experience I know, of course, that there are about as many definitions for the term “finished” among developers as there are for the term “snow” among Eskimos – about two hundred. And I’m sure we’ve all heard them before.
The list is almost endless.
A Story is finished when its implementation meets the acceptance criteria and if all test cases created for it have been completed successfully.
Naturally, this presupposes that acceptance criteria have been described at all and that adequate and conclusive test cases are available. This often poses major problems for the Product Owner.
You can only check the commitment when you use the term “completion”.
Therefore, it is a rule in Scrum that it is not OK to leave Stories open at the end of a Sprint.
So if you have 5 Stories in your Sprint and you can’t finish them, it’s better to completely close as many as you can and leave others open rather than to ‘almost finish’ all of them.
In order to do that, we need cross-functional teams and prioritized Stories in Scrum, so that other team members can continue to work on them in such a case of re-prioritization.
By the way, this is also the reason why every Story in Sprint planning is estimated by every team member and why the whole team has to agree on it.
This is not a team-building measure, but a necessary prerequisite for keeping the commitment later. Consequently, a commitment is always a team commitment. In Scrum it really only makes sense this way.
As we can see, the artifacts ‘Story’, ‘Cross-functionality’, ‘Planning Poker’, and ‘Review’ are also derived directly from the paradigms ‘commitment’ and ‘completion’ – simply by using common sense.
We haven’t talked about the third C yet, even though it’s the key to everything. At the same time, it causes most problems because it is the most difficult one to grasp.
Here, communication does not mean that a lot is communicated and that communication has priority over documentation. That’s true and that’s what happens, but it’s
not what we want to say here.
Rather, it is about the type of communication, the perspective, and its rhythm. And this reflects and defines the difference between vertical, feature-oriented and horizontal, layer-oriented development (as described in my article above).
For many software experts, Scrum introduces a change of perspective when it comes to communication.
At the center of communication we find the term “Business Value”.
Interestingly, the authors of SAFe have emphasized this perspective clearly and for good reason with their value #1: “Take an economical view”.
This perspective permeates the entire methodology from the central feature-oriented approach, which derives from the paradigm of effectiveness, all the way to the description and prioritization of Stories, which derive from the description of ‘motivation’.
If Scrum is well established, communication changes this way after two or three Sprints.
We want everything we do in Scrum to be seen from this perspective: When we create a
Story, when we have to make a decision regarding the architecture, when we have to compromise on the re-prioritization of Stories, etc.
This perspective is virtually impossible in horizontal, layer-oriented development. Here the basic idea of efficiency is communicated in a much more technical way; it’s more about technical feasibility and risks, etc. Quite often (not always and also not necessarily) the purpose is relegated to the background or remains implicit.
If you notice that Product Owner and the Dev Team are completely at odds with each other, then you will know that this change of perspective has simply not taken place yet.
In addition, the Product Owner and the Scrum Team will need some time to understand each other.
The Stories also have to be described in a way that allows developers to understand them so that they can start implementing them immediately.
Stories, therefore, reflect the state of the team culture, which manifests itself through communication.
Teams that harmonize extremely well don’t need much text in the Stories, while untrained teams need much more detailed descriptions. Often this has nothing to do with the complexity of the subject, but rather reflects the state of the team’s communication.
Retrospectives help to uncover and improve shortcomings in communication. This process also takes some time. It is the reason why the first few Sprints are often not as successful. The project manager shouldn’t lose heart and has to remain patient.
You can now use the 4 C’s as a guideline for implementing the methodology in your project or solving real-world problems.
Content of this article Much has been written about the agile transformation of organisations, its importance in the context of digital transformations, but also about
To avoid your agile transformation from failing, it’s most important to define goals and KPI’s – but above all measuring them! How and which you’ll learn here…
Agile – versus classic project management or more planning, less status Content of this article Time and again, I come across organisations that are in
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
