We were recently going through a few audits, and that raised some questions on the relevance of Scrum alliance in the audited context.
The exercise forced us to formalize the prerequisites of Scrum, to explain and illustrate in which contexts it is suitable or not.
In this article, we will share with you these elements that determine whether or not you are right to use Scrum and the Scrum meaning!
What is Scrum?
Scrum meaning is an agile system for complex goods to be produced, distributed and managed, with an initial focus on software development, although it has been used in other areas, including science, manufacturing, marketing and advanced technologies. Agile with scrum allows teams to work seamlessly to provide their customers with optimum value.
The prerequisites for a smooth and easy Scrum and Scrum principles:
An approach and development practices that lead to built-in quality, by building quality in the product rather than checking it after the fact.
The technical debt is under control: we know the existing one, we take the new one with a real strategy.
The development team is the lifeblood of the Scrum team: its members speak and are listened to by the rest of the organization. They make technical decisions and product decisions without their agreement.
Autonomy to accomplish its mission
The team is multidisciplinary with all the skills necessary to build the product from sketch to finish. We can make the development team up of at least 3 members.
We let the team gain the skills and expertise they need by taking the time or the necessary steps.
Do not share team members for part-time on several teams. They can participate in cross-functional communities or occasionally help other teams as an expert, but this is always secondary to their Scrum team.
The ability to self-organize
It does not make the development team up of more than 9 members.
The team is stable: it is above all the will of its members which alters its composition, not its organization. The organization assigns teams as atomic elements, rather than individually affecting people.
The objectives and not by perimeters drive the team. These goals are a collective team and not related to individuals on the team. More generally, the team evolves in an organization with a culture of self-organization and letting go. Many team members are showing leadership. There are several leaders. These team peers recognize leaders on their own and not chosen by the organization.
Building a product
The team has a strong vision that gives meaning and drives the product backlog. Stakeholders are strongly involved. In particular, they are present at the Sprint Reviews. The product built by the team is in the development phase, not in the pure maintenance or support phase. The support and maintenance of the product are normal and welcome, but the product is still in continuous development.
It’s the team, or at least the organization, that decides the future of the product, not the customer (s). A customer request is nothing more than a useful contribution to product decisions. It is not the customer who decides what will become of the product.
Reasons why Scrum runs malfunctions
Given these prerequisites, organizations often try to apply Scrum in unsuitable contexts. Here are the most common cases:
Lack of technical excellence
The team has not been trained in development practices that allow agility or the resources necessary for its continuous training are denied to them – particularly in terms of time and freedom.
Generally speaking, the organization does not give the necessary importance to technical excellence. The technical choices may be questioned by people who are however less competent, or at least more distant from the work to be done. Often, too, the pressure is put on teams to deliver more and faster; quality is not important.
When this happens, the result can be tragic. Trying to be agile, changing the direction of the product every few weeks, usually makes the situation worse if development practices do not manage these changes easily and safely daily.
Without technical excellence, agility does more harm than good.
Structure in skill centers rather than stable teams
Team members are resources, you can change according to project needs. The teams are not stable.
Often, too, some people are shared between several teams.
We also see a difficulty in letting people learn the skills they lack since we prefer to assign the ideal person on all projects, rather than raising the skills of teams that lack in the given skill.
In this type of environment, most of the elements of Scrum will be floating: estimates, planning, objectives, team dynamics, etc. The result will hardly be qualified as Scrum.
Difficulty in letting go
Directors, managers, or other departments (marketing, for example) have centralized decision-making power in the organization, and it is not natural for them to share it. It can be a question of product decisions, or of deciding on the organization of teams.
Not surprisingly, in this type of environment, self-organization is difficult if not impossible to put in place.
At best, the result can only be a facade scrum where the elements of the framework are applied mechanically.
Customer-driven product approach
Customer requests drive the product. Whatever the reason, it’s not the company that decides the future of the product, but the customers.
It is important to realize that this situation if it is not inherently problematic, will, however,
Conflicts with Scrum
In practice, a Scrum team in this situation will encounter many difficulties in defining its iteration objectives, the product meaning of the product backlog will be complicated to structure, and in a cascade, it is the whole meaning of the team’s work that becomes blurry. As for the role of Product Owner, it becomes useless or ineffective under these conditions. Even worse is that the Product Owner could then act as a project manager or manager and want to dictate to the development team how to do their job.
Also, in the absence of a real product focus, the indicators generally fall back on productivity measures rather than measuring the value created for the customer or the business.
This type of situation also leads to facade scrum. We will find the Scrum nomenclature, but not the team dynamics.
Should you use Scrum?
If these prerequisites are not met, or if you are in one situation, we have just described where Scrum is malfunctioning; it faces you with a choice:
Should we abandon Scrum or create a favorable environment?
There is no absolute answer. Its correct answer directly links to the vision for the future of your business:
These context elements are either normal, intrinsically linked to your field, or you have decided not to change them. You have to learn to live with it and probably give up on Scrum.
Or, on the contrary, you want to make a difference. In this case, the Scrum application will allow you to be guided by pointing out the shortcomings.
Scrum is an agile barometer
Most of the Scrum prerequisites listed above are great ideas no matter what, Scrum or not Scrum:
Technical excellence is not negotiable, whatever the context.
One of its best performance levers is the autonomy to accomplish its mission. Contrary to what our intuition says, it does not waste most of the time working on pointed subjects requiring strong expertise, but in communication, interactions and sticking. The model of a team capable of taking on an end-to-end mission takes the opposite view of this intuition and makes it possible to significantly reduce the time taken to produce value. This is not specific to Scrum.
The ability to self-organize is a strong lever for creating value. Thus, the decentralization of decisions is at the heart of Product Management and more generally in agile methods. It is also by self-organizing that a team discovers and designs the most efficient ways of working. It is also the best way to allow everyone more to flourish. Again, these gains are not specific to Scrum.
Building a product allows you to focus on what matters, and to give a lot of meaning to work, and therefore to allow teams to flourish while generating more value. Again, this point is not specific to Scrum.
This is how we can put it another way
There is no real reason not to aim for technical excellence, autonomy in accomplishing its mission and the ability to self-organize.
On the other hand, there are very good reasons to prefer building a product, but this is not always possible.
Unless you are in a situation where it is not relevant to opt for the construction of a product, you have everything to gain by setting up the prerequisites of Scrum. And that, whether or not you apply Scrum.
However, Scrum could be your best asset to help you set up this favorable environment.
Use Scrum as a barometer: If it’s complicated, difficult, painful or not fulfilling, then there is still work to be done in this environment.
Use Scrum in your transformation strategy as a tool to reveal problems and force improvements in the environment.
Kanban: The perfect alternative to Scrum
The other option is to just consider that it doesn’t fit your context.
Or, as mentioned above, you are not in a context conducive to the construction of a product.
Or, quite simply, you consider it too difficult or costly to set up the right environment. It is not in itself a bad choice as long as it is assumed and made in full awareness.
In any case, a good alternative to Scrum is Kanban, which is much lighter and more flexible than Scrum.
Where Scrum will collapse in the absence of a product approach, Kanban will find other levers to streamline the functioning of the team where Scrum will collapse in the absence of a stable and autonomous team, Kanban will help to frame everyone’s roles and responsibilities while forcing continuous improvement of the system if that is not enough.
Need help to judge the relevance of Scrum in your organization?
Do not hesitate to ask us if you would like to apply this type of framework to your team or for your organization, or to think about how to improve its functioning. It will be a pleasure to help you!