Scrum is a framework for implementing Agile project management. For several years, it has been strongly used and has become an indispensable tool for certain types of projects.
As a reminder, Scrum is useful for complex projects. It is not a method but a toolbox for an organization.
Low-Code on the other hand, is a solution that allows to deliver IT projects in a very short time. Delivering projects quickly can be a good thing, but it can also lead to a less precise work than if it had been done in more time.
Today we can put several elements under the microscope with Scrum and Low-Code, we have listed them below:
Under the microscope
1) Scrum is rather intended for complex projects, Low-Code makes most projects very simple.
As we mentioned above, Scrum is an Agile Framework that will decompose complex work into a succession of simpler tasks, carried out in several stages until the expected result is delivered.
With Low-code, the development part of this decomposition is very basic because the work of the developers consists mainly in making already existing modules interact, which makes it possible to transform complex technical projects into simple projects.
2) Scrum recommends one product backlog per product.
Thanks to Low-Code, a Scrum team can work on several product backlogs. Indeed, usually, a Scrum team works on only one P.B at a time.
With Low-Code, a Scrum team is able to work on several product backlogs at the same time.
3) The timebox recommended by Scrum for a reference sprint is one month but with Low-Code, this can be reduced to one week.
Scrum sets up regular meetings to ensure a good understanding of the customers’ needs through validation periods involving them actively. Other meetings will focus on improving the developers’ work environment.
These meetings determine the beginning and end of a work period called a Sprint.
According to the literature, the duration of a sprint should be as short as possible to allow for regular meetings and long enough to deliver value-added increments.
With Low-Code, the velocity of the team (the speed with which it delivers its increments) is greatly increased. If we don’t adapt the timebox (the duration) of the sprint, we risk losing efficiency.
4) A Scrum team can start working from a sufficiently clear scope
We will then refine the needs during the development. The needs will change throughout the creation process. We may very well change tracks, revise certain needs, submit other leads and thus have to radically change the main scope. Starting with a clearly defined scope, you can start working on the project, changing and refining elements along the way.
With Low-Code you have to be much more precise in expressing your needs before starting to develop. Low-Code, which is a RAD (Rapid Application Development) tool, must start from a scope that is not only well defined but also precise in terms of needs, otherwise there is a risk of blocking the development team due to a lack of sufficient input. We must work in more detail on the expression of needs.
Scrum gives us some tools, as long as we tolerate several cuts in the contract.
We listed three:
1) Several product owners for simple projects (to be carried out) in parallel
If the development team is working on several product backlogs, a pro rata number of Product Owners is needed to guarantee a time-to-market delivery for each of them (in line with current expectations)
2) Appearance of two peripheral roles: Head-Of Product Owner and Tech Lead
On the business side, the Head-Of Product Owner will have a cross-functional business view that allows him/her to set priorities between the various competing Product Backlogs. He/she will be the one who coordinates, optimizes and prioritizes the work of the Product Owners.
On the technical side, the Tech Lead is the technical referent of the Product Owner on one side and the developers on the other. He will make a first pass on the technical-functional solutions in order to guarantee the conformity of the choices before confirming the taking over of the development work.
3) Very experienced, very flexible and very responsive Scrum Master
In fact, a “low-code” Scrum Team will experience the same issues as a “classic” development team. But it will experience them much faster.
In order not to drown the Scrum Team in concepts to the detriment of their core business, i.e. the delivery of increments (i.e. parts of the product), the Scrum Master must be sufficiently experienced to propose robust solutions quickly and to keep the key approach of empiricism and co-creation alive…
Conclusion
Is Scrum a suitable framework to manage a Low-Code project?
The answer is yes, if you are not afraid of the cuts we have talked about.