Expert Opinion

The key role played by the client in the success of an agile project

  • #Agility
  • #Data
  • #Digital

Sylvie Rabie | Agile Coach | Keyrus

The interest shown in Agile approaches is there to be seen year after year. However, companies that turn to new working frameworks such as Scrum1 significantly underestimate the importance of their own involvement when it comes to ensuring the success of projects managed in Agile mode. Understanding the central role of the "Product Owner" is a decisive first step towards achieving success.

Every year, statistics produced by the Standish Group highlight the poor success rate of IT projects undertaken using the so-called "V-Model" method, which is, nevertheless, still the one most often applied in companies. By contrast, with the Agile mode showing success rates that are 3.5 times higher – even 6 times higher, for large projects – it is easy to understand why a growing number of organizations want their internal teams and external service providers to work in this mode, notably by adopting the Scrum working framework. Whilst there is much genuine enthusiasm for Scrum, its philosophy – centered on the creation of value for the users – is still too often misunderstood or misinterpreted, with the result that the adoption of Scrum is unable to deliver all the benefits expected.


One of the main causes behind the failure of IT projects is a lack of involvement by the client. Put simply, it can be said that with the old methods, the client's role was more or less limited to placing the order and, after x amount of time, taking delivery of a finished product, which may, or may not, prove suitable... By contrast, a fundamental principle underlying Agile approaches is that the client must be involved from start to finish in the creation process.

In Scrum, this continuing involvement is embodied by two players: the sponsor, who should ideally be a member of the executive committee, and who serves, at the same time, to both facilitate matters, and look after the project team; and, above all, the Product Owner (PO), who, within the team, acts as the permanent representative of the client – or, more accurately, of the users of the product that is to be built. Being neither the project manager in the classic sense, nor the one who gives instructions, the PO is, above all, the person who controls what the requirements are and judges where the priorities lie. An essential part of their role is to manage, rank, and prioritize the backlog, which is everything that must exist within the product in order for it to meet requirements in an optimal manner.

The backlog is not a set of specifications drawn up and then set in stone. On the contrary, it is developed and refined throughout the project. Moreover, there is one important thing that is particular about the backlog: the PO ensures that everything in it is expressed not in terms of functionalities that must be developed come what may, but in the form of express requirements, known as User Stories (US). These User Stories always specify who is the user concerned, and what they want and why, but without pre-judging what the technical response should be. By proceeding in this way, you eliminate the numerous functionalities that are requested on a "a priori" or "if required" basis, and that are not really justified in terms of use. When you are told that, on average, only 20% of what has been developed is actually used2, you can easily see the extent of the waste – of energy, time, and money – that could be avoided in most projects…


An Agile project consists of iterations each expressing a functional increment that can then be tested and validated by the users. An important task of the Product Owner is to organize these iterations and prepare them, by assessing each User Story in the backlog in terms of its "business" value. By contrast, it is the development team, and it alone, that evaluates the effort to be applied for each User Story. In this way, the PO can propose to the developers short iterations with a content that is realistic, in other words, that is achievable by the team and delivers value that the user will actually be able to gauge. In the Scrum framework, these iterations – which are known as sprints – generally last 2 weeks. In practice, each sprint aims to achieve a given set of user stories.

The sprint begins with a meeting at which the content proposed by the PO is discussed with the developers and adjusted according to the resources and skills available. By the end of this meeting, the development team will have confirmed what it is able to accomplish during the sprint. It then allocates the work amongst its members, with a clear understanding of how it will be accomplished. Meanwhile, it is up to the PO to re-incorporate into the backlog those work tasks that were put to one side.

The demanding and sustained pace of the sprints has the advantage of keeping the stakeholders involved over time and preventing them from becoming too far removed from the actual requirements. Indeed, each sprint culminates in a review session at which the users are invited to express their views on the increment delivered. In this way, you avoid pressing on with developing functionalities that are proving unsatisfactory, or are no longer relevant.


Organizations that are not yet well versed in Agile approaches struggle to understand the iterative and incremental nature of such approaches on the one hand, and, on the other hand, the principles of autonomy, versatility, and self-organization that must govern how the project team functions. Many such organizations also come unstuck in their choice of PO, believing that the role requires an IT profile. This is not the case at all : the PO is not involved in the "how" aspect of the work undertaken. Their added value lies, instead, in their ability to maximize the value of the product and the work performed by the development team. For this reason, it is better to assign this role to a person of calibre and stature, who has inside knowledge of the business line for which the product is intended, and who possesses solid communication skills.

A second common error is to imagine that, alongside their role as PO, the individual concerned will be able to carry out other duties external to the project. The reality is that their work liaising with the users, scheduling and refining the backlog, preparing sprints, and supporting team members demands 100% of their time. Lastly, the PO does not need to have detailed knowledge of Scrum, because they are supported throughout the project by another crucial player : the Scrum Master, who constantly ensures that the rules of the game are being followed and that all is well with the team. Whilst the Scrum Master is no more of a technician that the PO, and is external to the business line, they must, however, have a thorough grasp of Scrum's intricacies. They need this if they are to be able to both convey, and durably embed within the organization, the 3 principles that underpin Scrum's philosophy and the success of projects that use its framework: transparency, screening, and adaptation.


Sylvie Rabie has spent 20 years working in several different digital and web agencies on numerous projects covering all fields. She has acquired considerable expertise in the design of IT and multimedia applications, as well as in project management. A certified Scrum Master and Product Owner herself, she has been working in agile mode for more than 20 years. As an Agile coach at Keyrus, she provides training and support to implement agility within clients, both for given projects, and as part of large-scale Agile transformations.


1Scrum is a working framework and a set of rules of conduct for projects that were formalized in the mid-1980s to help develop complex products.

2Source: Standish Group, CHAOS Report 2015. Only 7% of functionalities developed are used all the time, while 13% are just used often, and 45% are never used.