I joined SilverStripe 18 months ago in the new role of Marketing Manager. I came from a non-tech company, and my only experiences with web development were waterfall. Agile was a whole new concept to me. It sounded great on paper, but I wasn’t sure how it applied to marketing and communications.
Initially I viewed the Kanban boards and burndown charts around the office from afar as I worked independently from scrum teams. But we’re huge fans of Agile at SilverStripe, and we try to adopt an Agile mindset across all areas of our business, not just our development teams. Every team from HR, to operations, to accounts have embraced Agile and found their own ways to apply the Agile manifesto.
It was only a matter of time before we created a scrum team for our communications roles, bringing together marketing, education, community and development experts into a powerhouse called The Storytellers.
I was given the huge responsibility of Product Owner for this new scrum team. I remember vividly our wise Development Manager Clarion Coughlan giving me this piece of advice when I started:
It will be the single hardest and most rewarding role you ever hold. There will be times you want to give it up, but in the end you’ll love them and love being a product owner
She was right. There were many, many mistakes along the road. There were a few tears. But looking back on the first few months, the highlights far outweigh the negatives. We launched a new website www.silverstripe.com in just 6 weeks by applying lean and Agile principles, a project that had been on the “to-do” list for years. We built our own life-sized DevOperation game for PHP NZ and won the best exhibitor at ALGIM for two years running.
I’ve led teams before, but being a product owner is completely different. The learning curve was steep, but I was surrounded by SilverStripers who live and breathe Agile, so I always had someone ready to help when I got stuck. I wanted to share my own advice for any other newbie product owners facing the same challenges.
Hopefully you can avoid these mistakes, and find your own to make!
1. Don’t micro-manage
I’m sure my teams will chuckle when they read this one. I still struggle with this as I’m a self-confessed control freak. However, for Scrum to work you need to trust your team and your Scrum Master. I am lucky to work with a fantastic Scrum Master Marcello Commisso. In the early days we clashed often. I’m sure this is natural as you work out each other’s style and strengths. As a Product Owner you need to work closely with your Scrum Master, and both people need to be open to honest feedback.
At first I wanted to know every detail, I’d nervously examined the Scrum board wondering how we’d ever finish all of the tasks by the demo deadline. I never left assignments at school to the last minute, so this was torture. I thought things would go faster if I just told people what to work on. Miraculously, we always did deliver on time, even if it meant a mad dash to the finish line.
In time, the team gelled and their pace across each sprint evened out. The rush to sprint deadlines dissipated as we learnt how to work together smoothly. The team learned to plan their approach to stories without needing top-down direction. Those early teething problems were all part of the team coming together. We were just going through Tuckman’s stages of group development with the natural forming, storming, norming and performing cycle to move through.
Marcello has years of Agile experience and I slowly learned to trust when he told me to chill out and stop micro-managing every little detail! If you’re a control freak by nature, you’re going to find Product Ownership hard at first, but it’s really good for you in the long-term!
Although you may feel that your neck is on the line as a Product Owner, you can’t control the team’s schedule or worry about how they allocate work. The Product Owner sets priorities and provides direction. Often I know far least about the technical side of how stories are delivered, I have to trust that the team will find the best way to deliver the business outcomes needed.
Trusting the team also allows self-management. People can put their hand to take on tasks based on their strengths, rather than having work allocated. Ultimately this leads to better solutions than micro-managing ever could. So let go and embrace an Agile mindset!
2. Don’t rush. Good things take time
Building a new scrum team and becoming product owner is a long process. I’ve now been in the role one year but I only consider myself slightly above beginner level!
You need to have faith that a few messy sprints at the start are just the team finding their feet. Have patience that the team will find their rhythm and build on their efficiency.
Sprints are never the same, and being ultra productive in one won’t always predict success in the next. Stories with a lot of unknown variables or new frontiers will affect your efficiency. For example, we’re currently working on migrating smaller SilverStripe community sites like Developer Docs to the newest SilverStripe Platform feature Stack Share. We’re working on these stories as the product is being developed (super early adopters!). This means that the team has factored uncertainty and likely surprises when sizing stories. I trust that the team will do their best even if the sprint look less efficient on paper.
If the team occasionally fails on a sprint goal because they’re trying new techniques or setting ambitious goals that’s actually a great thing. Continuous improvement is impossible without a few hiccups along the way. If this does happen use your retros and discuss openly (ie don’t point fingers!) to find out why this happened so you can keep moving towards a better, more efficient team in the future.
While becoming a high performing scrum team and first class Product Owner takes time it’s also important to track your improvements so you know you’re heading the right direction. Work with your team and Scrum Master to come up with measurements that work for you.
In my teams, we use OKRs (measureable quarterly stretch goals), burndown charts, sprint velocity and demos to track progress. These are handy markers that keep us improving and help your confidence as a Product Owner grow.
The more a team works together, the better your estimates on the capacity of team will be and you can have more certainty in planning as a product owner.
3. Don’t worry if you don’t know everything
As mentioned, I don’t have a development background. My specialty is marketing. I don’t always understand the deep technical details, but I try. I ask a lot of questions and I’ve learnt not to assume that everyone is on the same page at the start of the story. It’s your responsibility to ensure the team delivers on the outcome required. This means taking the time to explain the background. Teams create the most amazing things when they fully understand the “why” behind the stories you’ve prioritised.
Never be scared of asking questions when discussing technical matters. It’s always best to have open discussions before a story is started, rather than have things built that are later discarded.
Swallowing your pride early is far better than wasting people’s time later...
...but also understand you’ll never know everything. It’s tech, afterall. Things change so quickly in this world that it’s impossible for you to know everything. That goes back to trusting your team. They’re each experts in their areas. Ask for their input and draw on their knowledge. I’m constantly asking the developers in our team for input on our marketing, especially when we’re communicating commercial messages to our amazing open source community.
Ask for feedback whenever possible. You won’t always like what you hear but it will make you a better Product Owner. In team retros and 1-on-1 catch ups with Marcello I always take note of ways I can help the team improve by being better myself. I still make loads of mistakes but I’ll keep trying to improve.
Learning to love Product Ownership
Clarion’s prophetic advice was spot on. I’ve learnt to love being a Product Owner, thanks largely to the guidance, patience and support of Marcello and other SilverStripe agile experts. The Storytellers grew and our efficiency slowed as we took on a wide variety of tasks. Marcello and I worked with the team and using a self-selection exercise created new two teams: The Neuron Boosters, responsible for our sites and looking after our community happiness, and The Firestarters, responsible for bringing new people into the community to use our products and services.
Two new teams means starting the learning curve again. It means twice the planning, twice the user stories, twice the standups and twice the retros. But it also means twice the fun, twice the joy of a great demo and twice the awesome people to learn from and with.
If you’re learning to be a product owner or wanting to improve check out our Product Owner Mojo Booster. This guide is packed with SilverStripe experience on Product Ownership for embarking on this awesome challenge.
Download our guide for FREE now!
Banner photo credit: Darkuncle
I'm very interested in estimating and measurement, as it's something that comes up in discussion about agile in a software context. How far ahead do you estimate the difficulty of your user stories or PBIs? Do you, for example, have a realistic idea about things that would be delivered in 2-3 months time?
Posted by David, 08/12/2017 5:06am (5 years ago)