Scrum in agencies: where does the Product Owner live?
Implementing Scrum in a standalone organisation (such as a product company) derives directly from the framework. Yet some aspects are open to interpretation for Scrum teams in an agency providing software development services to clients. Both The Scrum Guide and most literature on best practices of implementing Scrum lack the notion that the so-called “organisation” may be, in fact, two separate legal and business entities: the agency and the client. How do you apply The Agile Manifesto’s “Customer collaboration over contract negotiation” when the underlying “organisation” exists precisely because of a contract?
As I worked as a Product Owner on the agency side of this type of relationship, I’ve started becoming skeptic about the potential of such setup. Over time, thanks to
- added experience (both then and after switching to a product company) and;
- exchanging ideas with other members of the Agile community (the Agile Connect Lisbon meetups have been a particular good venue for this);
this skepticism developed into a view on this problem, relying on context.
Depending on the context, different Scrum team setups work better than others, and in some contexts the best option is ditching Scrum.
Let us now discuss these setups; I’m writing with the agency in mind, so I’ll often refer to the agency as “you”. To frame the discussion, let us have present the definition of Product Owner:
Product Owner on the agency side
In this scenario, the agency provides the whole Scrum team as a service: Development Team, Scrum Master, and Product Owner. With no other roles defined, we are left to interpret people on the client side (even at the C-level) as Stakeholders. These provide valuable input, and feedback, that the Product Owner shall take into account towards decisions regarding the Product Backlog, priorities, etc.
But sooner or later, from within those Stakeholders, a HiPPO appears (for those unfamiliar with the term: Highest Paid Person’s Opinion). Good luck telling that HiPP that his O needs to be considered at equal footing with the input from any other stakeholder, using more objective criteria than “CEO says”, and that the decision whether his feature request makes it into the product lies with some other company’s employee.
This quickly institutes as normal a Product Owner smell: “The Product Owner is underpowered and does not act as the guard of the backlog” — also known as underpowered proxy Product Owner . This is specially true when the client organisation does not fully embrace either the use of Scrum in particular or the Agile principles in general.
This may also be a sign of a Scrum cargo cult: the client never wanted to buy product ownership as a service, but “that’s how we [agency] do it”. Client and agency are not aligned on what the former is buying from the latter. If the service provided to the client includes full product ownership, this needs to be crystal clear, both in the contract and in our value proposal. You need to provide real product ownership (which should “look” more like product management and less like project management). To do this, you need someone who lives and breathes the client’s business, both on knowledge and dedication (100% to one Scrum team).
I see this as very hard to cope with on a case per case basis in a generalist agency. It is better suited for a company which focuses in developing products for one vertical (or a narrow set thereof).
Product Owner on the client side
If you don’t have what it takes to provide product ownership as your value proposal, or the client doesn’t want to buy that service, then it is up to the client to own their product. They have the business know-how, the money, the corporate authority, and they assign someone within their own company to call the shots on this product. If the client needs help with requirements analysis, then provide this within the cross-functional Development Team (“The Product Owner may do the above work, or have the Development Team do it.”). Don’t force-sell a Product Owner just because the client needs an analyst.
In this setup, I cannot stress enough the importance of a strong, full-time, dedicated Scrum Master. Reducing the Scrum Master to someone from elsewhere in the company who acts as a part-time therapist who makes sure meetings begin and end on time is wrong in any case—but in this one, is a recipe for disaster. The Scrum Master will be the key mediator in the relationship between the Development team in one company and the Product Owner in another company. Thus, as the keeper of the process, he/she might have to push back on some of the client’s wishes. He/she must be able to do so with propriety, and that’s only possible with a fully capable and dedicated (hence committed) Scrum Master.
What if there’s no Product Owner?
This happens when the client does not buy in to hiring product ownership, but does not fulfil that role on their side either. They might assign a manager of some sort as the point of contact, but lacking the right skills, mindset (the client and/or this person do not trust Agile, or do not yet trust you enough to go for it), remit, and/or bandwidth (the company has a lot more on the plate for this person). This person is not a Product Owner.
This all too common situation would ideally be detected early on, and for an agency that is serious about providing high-quality and high-value software development services this should be a watershed moment. At this point, two things are, for me, evident.
If there’s no Product Owner, there’s no Scrum. Insisting on Scrum because “we do Scrum” in this scenario is pure cargo cult. (This reasoning also applies, for instance, if the client is not willing to commit to hiring a stable and properly sized development team.)
If there’s no Product Owner, you might as well not have a product at all. If the client is not willing to have a full-time person (either their own or from the agency) devoted to the continuous quest for value, they’re probably not serious about this initiative as a long-term one — or they have not matured it enough
Depending on how you, the agency, position yourself commercially, there are a couple of valid options for the agency at this watershed moment.
Offer your services in the form of a project
This means branding and managing the relationship between client and agency as a project, from beginning to end (two things that a project, by definition, should have). Spec the project, assign a project manager, call him/her just that, and deliver—skipping Scrum and Agile altogether. The result will not be the best, IMHO, but both parties will learn a lot. This project may give origin to another project that builds upon the first one, and after a handful of (small!) projects both you and the client will have learned more:
- about each other; and
- about the common thread of these projects.
Now you’re in a better position to establish a less intermittent relationship that sits on top of a product vision, where makes much more sense to apply an Agile framework such as Scrum.
Politely say ‘No’
You can (and should) have ground rules. You can have a ground rule of using Scrum (or, putting it in another way, only taking upon initiatives where it makes sense to apply Scrum).
You can (and I think you should) have ground rules regarding the type of work you sign up for — e.g., you just don’t do PHP.
You can (and I think you should) have ground rules regarding how you conduct your work and your meta-work (for instance, Thoughtbot don’t do “fixed-bid, fixed-feature-set proposals” nor “provide itemized invoices to clients showing individual pieces of work that were done”).
If the opportunity before you goes against your ground rules, then you should walk away, instead of providing a lesser service only to close another deal. However, you have to be confident that those ground rules really relate to how you perform best. When you set your terms this boldly, you must make sure that you will excel, to the benefit of your client and of your reputation.
The view I’ve developed about this subject (and is not written in stone) can be summed up as:
- the Product Owner should only live on the agency side if product ownership is specifically agreed to as part of the hired services; otherwise, he or she will soon be underpowered to fulfil that duty;
- when the Product Owner is someone from the client, the key figure in the agency regarding the day-to-day relationship with the client towards delivery is the Scrum Master, so it becomes even more pressing to have someone properly skilled and trained for the role, and 100% committed to one Scrum team;
- if the client will neither buy nor provide an effective Product Owner, there is no room from Scrum, and probably not (yet) for a continuous relationship either; in this case, within the boundaries of your ground rules, either progress through some small projects, or turn down the client right away.
This post represents my personal opinion on this subject, not that of any company I work at/for on this subject area.