Role Playing in Agile

when i first took on product management, i started learning techniques like how to understand the market, strategy, swot analysis.

while i didn’t write proper user stories, i prioritized requirements and was there for the team to describe scenarios, answer questions, updates on news, test the application, and give feedback. my time was split between doing product management and product ownership. i didn’t see any difference between them.

after doing this for a while, i’ve stopped doing the classic product management tasks and concentrated on user feedback. turns out, user feedback points more to what we need to do (or not do) than theorizing (read: gambling) on roadmaps. who knew?

still, my view of what my job is didn’t change. it included both outbound and inbound activities. today, the teams i coach, have product owners (who use to be product managers), and i advise them to take this view as well. yet, i’ve been smelling something is off with that setup. i couldn’t put my finger on it, until recently.

a one-two punch

a few months ago, i went to practical agile ‘s advanced product owner workshop. (disclaimer: the practical agile people are partners for work, friends and all around awesome people.) the content of that the workshop aligned with my vision of the po and pm and covered topics from personas to prioritization.

as discussions started to come up, i saw that they were significantly more po-minded rather than pm. people wanted to know how to write better stories and how to manage backlogs better. there was a lot less interest in product management skills.

something felt out of place, yet i couldn’t say what.

the second event that made it clearer, was melissa perri 's keynote at lean agile scotland. (disclaimer: melissa perri is a great trainer, speaker, friend, and all around an awesome person.) melissa’s talk was about how product owners have lost the product management focus. instead of doing product discovery, by talking to users and customers, they spend their time, wait for it, writing stories.

no matter how good you get with internal product ownership, if you don’t interview the users, you’ll probably be building the wrong thing, maybe in a better way. that requires product management, not product ownership skills.

light bulb!

split personality

if you check the scrum guide’s definition of the po , you’ll see information on working with the development team. the only hint about actual product management is in the magical and vague word “value.” that’s it. everything else is about backlog management, prioritizing, and helping the team, which is very valuable.

imagine if the po is there only one day a week to support his or her team. that wouldn’t work.

what if the po is there four days a week for the team? that doesn’t leave much room to product management. that won’t work as well.

the role is simply too big.

with the success of scrum (and sometimes the dysfunctional implementation of it), companies have separated the roles. analysts go to interview users, create roadmaps, and choose the features to implement, while the product owners help the team in their own little circle. however, that means they are now just part of a waterfall that starts with the decision makers.

the agile team cannot do any discovery, but can only execute an already decided plan.

third punch’s the charm

developers. testers. managers.

all those are skill-intensive roles. sometimes too big to fit the bill, and then we have two options.

our default option is to create a new role. like devops. or automation tester. or front-end developer. or architect. we like to put things in boxes and give them names. we then like to put people in those boxes, and people identify with the roles, so it’s a win-win.

until the new box  feels up with work. work that may not be effective.

remember the po who’s not doing product management anymore? she’s writing stories for four days a week. after all, she needs to convince management the role is worthy, or the devops person who starts writing superfluous automation platforms when they may not be needed.

the more effective option is what we did with developers and testers. grow the team to include skills and knowledge to do the work. spread those around, regardless of roles, and focus on getting the job done.

in the case of the product discovery, that means enough capacity to do enough product management and product ownership in the team. we go back to the whole team agile approach.

agile role play

in her talk, melissa said that agile is not enough because we need to add the product discovery into the development cycle. instead of being just an execution methodology, to be a complete product development framework.

what is agility, though? it is an organization capability to respond to the market. that includes the whole product development cycle. agile doesn’t need extension. we need to downplay our role obsession and instead focus on building all the needed skills in the team.