Product Owners- Tips for engaging non-Engineering in the agile process

Question

From my experience, in mid to large size software companies, agile most often grows out of the eningeering organization. Either grass roots up, from the team level, or exec sponsored from the engineering senior management. It means the development organization is often using agile well before the rest of the company.

The challenge is the product management organization is still operating in their traditional model. This can lead to a major roadblock to agile driven project adoption. The dev organization is trying to operate in an iterative style but requirements are still delivered in the old style requirements documents and all detailed up front. Resistence to going to the agile model can often be high. "I don't care how engineering builds it, just build what I want." Product management orgs also rarely want to make the time commitment that a Product Owner needs to make. They are too busy running off to the next customer meeting.

I've know of two models for trying to get the product management org involved.

• Project Manager/Scrum Master acts as a PO interface: Works with the PM org to coach them and translate their requirements. Fills in for the PM as the PO in regular meetings. I've personally worked with this model and I don't think it works well.

• Create a Product Owner office: I've heard of a mid-size company where the VP of Eng created a Product Owner office. This office is in engineering and is staffed by technical people with business knowledge. Product management delivers their requirements to this office and the normal agile process goes from there. No information on how successful (or not) this is.

Any suggestions?

Answer 1

I would approach the situation from the change management perspective. What you described is a common problem and happens all the time and not just with Agile. The change comes from inside the group - from developers - and instead of adapting the groups chooses to fight against the new norm.

What you need is something shown in this video. There's a guy who starts dancing - a funny one -, and for a while he dances alone. A bit later the early adapter joins him, he shows him how-to dance and they dance together, while others are watching. After a couple of minutes the rest joins and they dance together. For me the first dancer is an open minded PO, the dance is the Agile, however things won't happen that fast.

The TODO list for starting something similar:

1. find the open minded PO
2. help him to become a initiator
3. use behaviour to change an organization

Finding the right PO is a hard task, but there must be a guy who was a developer before, or is curious about new things. I'm pretty sure that he exists. Without him the change won't happen, so you have to find him.

Helping him to become an initiator means that you should work with him to become a great PO. There's no good recipe, but I believe that the shuhari method is the best for this kind of action. First (shu) he has to learn what Agile means, second (ha) he has to make his version of Agile and third (ri) he continues his journey alone, be a master and spread the word.

The last step requires him to know how to change an organization using his behavior. The Influencer book is the best start. It describes how to change anything by behavior. The PO needs this knowledge, because a funny dance attracts more people than a fancy hard to adapt software development methodology.

I talked to a successful project manager once who led the most successful organization in his former company. He introduced empowerment in his organization. He lived with the norms required to make it happen and after a while his colleagues showed up and asked for the recipe. And the change started to happen. Of course not everybody followed, but after reaching the critical mass they wouldn't have other choice. I'm aware that this is not an agile story, but it's about the change, so I think it applies.

Answer 2

Typically my preference would be to build teams around products, target customers or target markets. In that scenario product management would be just a different part of a team that also includes all the engineering roles. That, however, might not be feasible.

Some organizations, the one you describes seems to be one of them, are organized along functions, product management in one part of the organization and engineering in a different part. There are different techniques that I have used with varying degrees of success in the past.

One option that worked in some cases is having one person on the engineering team interfacing to product management. This person would be the product owner from the engineering team's perspective. Even though product management would still write up everything in large batches, the product owner can then break it down into smaller pieces for the team. My recommendation would be to then make available to product management each smaller piece as it is completed, inviting them to review what has been accomplished and provide feedback.

The first few of these "review" meetings can be very challenging. However, in my experience there are always members of product management who discover the value of having early insight into the progress of the project and having an early opportunity to provide feedback. Once they start seeing this as an advantage chances are product management will start pushing for more. As a result you have started a process of incremental improvement towards smaller requirements sets and towards a more agile process.