Agility is the framework for any e-commerce project, which is why it is at the heart of SQLI's practices, in particular through Scrum. Organisations who turn to us are experts in their respective business sectors, but not necessarily in web technologies and the Agile framework. Clients are generally novices in this area. However, their commitment is essential to the success of a product designed in Scrum.
How do you explain to clients the role of stakeholders and, above all, the key role of the Product Owner (or 'PO' for those familiar with Agile)? How do you give clients the means to play their role and make progress throughout the project? How do you compensate for the inevitable shortfalls?
What is referred to in our jargon as a "lack of client maturity", is classified as a "risk" at the beginning of a project and shared with the client. This step is necessary, but is not enough on its own. Actions must also be defined, in order to avoid (at best) or reduce (at worst) this risk.
Engagement is one of the values of Scrum and it is particularly important to share it with clients. Client engagement, particularly as a PO, is essential throughout the project.
Firstly, it is important not to underestimate the work that this will represent for the Project Manager or Business Analyst, which can take days over the course of a project. It must be planned for in the schedule, as, in addition to their usual tasks, the Project Manager/Business Analyst will need to provide training on the use of tools and specific terms ('sprint', 'backlog', 'review', etc.), and ensure that the client is invited to and participates in events. Explaining the basics of Agility is useful during the kick-off, but it must be combined with what could be called ongoing training until completion of the project.
Inviting clients to sprint reviews, where they will play the role of stakeholder, is essential. This role is clear from the client's point of view and this is not where the difficulty lies.
It lies in the role of the PO, who is not (only) a tester of deliverables, who is called upon once during the specification workshop and again following delivery. This approach is more like the famous V-model (or waterfall model), where the client and agency meet twice during the project. Avoid the pitfall of reproducing this model by simply transferring it from the level of the project to the level of the sprint.
Our clients should be involved in all events that require the PO: the sprint planning, sprint retrospective and, of course, sprint review (to which stakeholders should also be invited). The PO should also be involved more outside of events, in order to confirm functional and technical choices together. The more the PO is invited, the more they will be present and engaged.
What if the client does not have the time? Often busy with other tasks and sometimes absent (maternity leave, sickness, etc.), they may not be able to handle all or part of their functions. It seems to me illusory to imagine that providing support is always enough. What have we observed during our projects? The Project Manager/Business Analyst acted as a safety net and took on a good part of the role of Product Owner.
This of course ensures delivery of the product, but is it ideal?
A product cannot be successful without a Product Owner who is present and active from the first to last sprint.
What happens with the V-model? The functionality is specified, developed and then delivered The result is a high level of dissatisfaction among end users, who never or seldom use the functions. And disappointment for the client, when they discover a deliverable that does not meet their expectations. There is also often delay in the schedule when development has to be redone.
To avoid unpleasant surprises upon delivery, Scrum involves clients in all sprints. A PO who has properly carried out their role should never be surprised during the review. This is a real benefit for clients and the reason why SQLI teams adopt Scrum.
It is thus up to us, and the Project Manager in particular, to communicate this type of benefit to the client.
So let’s go further with an iterative approach!
The Agile manifesto focuses on individuals and their interactions. SQLI cannot be agile alone: interaction with the client is essential. We need the best possible POs.
How can we achieve this? How can we improve the involvement of our clients on a daily basis? How can we ensure quality support to share our expertise with them? Let us therefore adopt a Scrum approach and ask ourselves these questions in an iterative manner, during each sprint retrospective, for example, and, of course, each project review.
This way we can continuously improve.