“Owning” an online product as it declutters, rebrands, replatforms, and “responds” to desktop, tablet, and smartphone devices can be a scary business.
I was asked to share these tips, based on my experience of The BMJ responsive design and Drupal 7 migration project, to help fellow product owners as they grapple with Agile, scrums, sprints, backlog grooming, stand-ups, and “show and tells.”
-
Scrum teams change. Get over it
The last time I was in a scrum was between 1977 and 1982, and for most of those five years I was in the second row with my arm round David Severn and my face wedged against Ian Farrell’s backside. We got to know each other very well.
The BMJ_ scrum team changed more regularly than my school rugby team. Don’t let this unsettle you. Some developers in BMJ’s Technology team were pulled on to different projects, and contractors joined as the project progressed.
It’s not your call as product owner who is in the team. They will learn from each other (and from you), and the more people who get to know your product in the technology team, the better. Single points of failure are not good. This is probably why the team at BMJ rotated the role of scrum master, which worked really well.
-
Beware sprint saboteurs
Every two weeks we met to score and prioritise tasks and bugs in the backlog, and a follow up sprint planning meeting gave us a list of scored stories to keep everybody busy for the next fortnight. You’ll probably face pressure from business colleagues and others to rejig priorities and slot in new tasks.
Hold your nerve (even if they look like they’re going to cry. Or shout at you. Or both). You’re the product owner with the best sense of what needs doing. Every sprint is sacred (to adapt a line from Monty Python), and if you add something, it will almost certainly mean another task won’t get done.
-
Know your front end from your back end
The panto horse analogy really does apply here. Your scrum team will probably consist of front end and back end developers. You don’t want your back end twiddling its thumbs while the front end is struggling to keep up with all the design challenges you’ve given it to do. But don’t get too hung up about this. The important thing that the team as a whole is working on top priority tasks.
-
No showing and yelling
At the end of code release there is a chance to showcase what the team has achieved. If you’re smart you’ll invite lots of people across the business to see this.
Think of this “show and tell” as a slot at the Edinburgh Fringe, so do the equivalent of handing out flyers in the Royal Mile - don’t just invite your mates, who will give an you an easy ride. When your audience arrives, imagine they have paid for a ticket, so try to make it entertaining. Be respectful, even if they’re asking awkward questions. Their feedback will help you plan future sprints.
Lead the session by setting the scene and explaining what the sprint achieved. But don’t hog the limelight. Hand over to scrum team colleagues to explain stuff in more detail. This applies especially to anything with an acronym. And BDD. And something called Jenkins.
Finally, don’t spend too long showcasing a back end admin interface that will only be used by a handful of editors, however proud the team are of it. Try to focus on things that will interest your audience the most.
-
Don’t give up the day job
If you’re a product owner you’re probably also a line manager. Your team will end up working on the product after it goes live, so their feedback is gold dust. Involve them at every opportunity, particularly with testing, and remember that they are doing a fantastic job keeping the current product updated while the new one gets developed. If, like me, your Myers Briggs is ENFP, having a ISTJ co-pilot (or something similar), is essential. Otherwise you’re stuffed.
-
Be a jack of all trades
At times you will look back nostalgically at the days when you had a dedicated project manager and a budget for user testing. (This involved sitting behind a screen in St Albans, watching a bunch of doctors confuse you with The Lancet and moan about why the contents aren’t on a blue front cover anymore).
Those days are long gone. User testing now involves sharing the pre-live site after every release with editorial board members, colleagues, friends, foes, and random readers you are allowed to email without upsetting the data protection applecart. Make sure you log their feedback (it’s priceless) and use it to inform future sprints.
Life can be tough without a project manager. It’s down to you to arrange pizza and beer on the night you do your “first public release” but it can mean you get closer to the actual development team, which is a good thing.
-
Double-desk David
There really is no substitute for sitting with the scrum team. You will accomplish a lot more in each sprint, and you will learn a lot in the process. The team will want you to clarify tasks, look at designs, and warn you about any show-stoppers. I tended to stay after the daily 10 am stand-up meeting whenever possible. BMJ’s Technology department had better coffee, comfier sofas, and home baking. It also has more chocolate than anywhere else at BMJ Towers.
-
A bug’s life
You will launch with bugs. Don’t believe anyone who tells you otherwise. So make sure you get some “post-launch” sprints approved to fix them. These sprints can also include any features that don’t constitute “minimum viable product.”
-
Minimum viable product
This term stinks. It sounds like you’re consigning your cherished newborn digital product to the online equivalent of a special care baby unit. But applying this definition does help you prioritise. Do you really need the ability to filter online article responses according to the writer’s horoscope? If you do, can it wait until after you’re live?
-
Take a break
In the old days a project usually had a launch date, so you tended to put your life on hold and book a long overdue two week holiday within days of it going live as all the bugs appeared. So did everybody else. But Agile projects aren’t subject to the same constraints, so don’t feel guilty if you abandon the scrum team for a week or so midway through the project. It’s important that they do the same thing too, so you all stay refreshed.
David Payne is digital editor, thebmj.com
The BMJ (formerly the British Medical Journal) is an international peer reviewed medical journal dating back to 1840. Online since 1995, thebmj.com is updated daily with_ The BMJ’s_ latest original research, education, news, and comment articles, as well as podcasts, videos, and blogs. The BMJ’s team is based mainly in London, although we also have editors elsewhere in Europe, in the US, and in India.