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 Scrum best practices miss that the so-called “organisation” may be, in fact, two separate legal and business entities: the agency and the client. How do you apply “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 its potential. 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, namely at the Agile Connect Lisbon meetups;
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:
Scrum 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, we’re left to interpret people on the client side (even at the C-level) as Stakeholders. These provide valuable input the PO shall take into account in decisions regarding the Product Backlog, priorities, etc.
But sooner or later, from within those Stakeholders, a HiPPO appears (Highest Paid Person’s Opinion). Good luck telling that HiPP that his O needs to be considered at equal footing with that from other stakeholders. What’s more: 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” — the underpowered proxy Product Owner . This is specially true when the client organisation doesn’t fully embrace either Scrum in particular or Agile 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 to be provided includes full product ownership, this needs to be clear in the contract and in our value proposition. You need to provide real product ownership (which should “look” more like product management and less like project management). For this, you need someone who lives and breathes the client’s business, in 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).
Scrum 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. So 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.” So 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 just
- acts as a part-time therapist, and
- 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 between the Development team in one company and the PO in another. Thus, as the keeper of the process, they might have to push back on some of the client’s wishes. They must be able to do so with propriety. 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 doesn’t buy in to hiring product ownership, but doesn’t 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. 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 also applies, for instance, if the client won’t commit to hire 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 won’t have a full-time person (on either side) 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 position yourself commercially, there are a couple of valid options here for you as an agency.
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. One of them may be to use 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.
Key takeaways
The view I’ve developed about this subject (and is not written in stone) can be summed up as follows.
- The Product Owner should only live on the agency side if product ownership is specifically agreed to as part of the hired services. Otherwise, the PO 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. It becomes even more pressing to have someone properly skilled and trained for the Scrum Master 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, stick to your ground rules, and either progress through some small projects or turn down the client right away.
This post represents my individual professional opinion on this subject, not that of any company I work (or have worked) at/for on this subject area.