When I started working as a product owner for the online shop at Telefónica Germany (also known as o2) in 2009, Scrum had already been established in the portal development unit. During the last four years the way me and my fellow product owners work has changed and matured significantly. And I think this is part of the magic of Scrum: always trying to get better, questioning the way you work and constantly improving things that need fixing (this is why retrospectives are so important).
These are my top 10 learnings of the last four years as a product owner.
1 Confront the team with the topics early
Soon after I took over the online shop team we established weekly backlog grooming meetings where the upcoming stories were discussed and estimated. In many cases the team had much better solutions for stories than I or my peers from online marketing had in mind. The team adds value. We use the meeting to discuss rough requirements and detail them out together. Avoid bringing a story completely unknown to the team into the sprint planning as it will dramatically lengthen it – depending on the complexity.
2 Have fun, celebrate success
That’s an easy one. If you fill in a little bit of fun during meetings they are so much more fun, the team is a lot more motivated and they enjoy working together with you a lot more. If the meetings you are responsible for are fun to be in, people will like to attend. And do not forget to celebrate sucess. Bring candy to the sprint review. Champagne or beer after a major launch – depending on the team’s preferences.
3 Attend the daily standups as often as possible
But if you do so, do not try to influence the sprint. Trust the team’s self organizing power. Simply listen and be helpful. After the team is finished with its topics I usually give updates on what’s happening in the company. Almost every day they ask questions concerning the stories they are currently working on, so it’s a perfect opportunity to clarify things after the standup meeting and before they dive into their workday.
4 Treat the team well
Say thank you, praise their work after the demo, be constructive with feedback even if it’s negative. Be understanding if there are personal problems or sickness. You’ll get rewarded when you desperately need their help someday. They’ll love to help you in case of an emergency. What goes around, comes around.
5 Avoid islands of knowledge.
We have always encouraged the team members not to specialize too much in a specific area. Have a frontend developer implement a backend service. Let a backend guy build a GUI even if it takes longer. Have the team members take turns doing the sprint review, so they can all work on their presentation skills. Holidays and sickness won’t hurt you that much if any story can be implemented by any member of the team.
6 Form component teams
While we were organized in cross functional teams in the early agile years (2006-2010), we have moved to component teams responsible for one application each, such as the online shop, the selfcare portal or the company’s SSO-application. If a team is fully responsible for an application, they’ll establish a feeling of ownership for it. When there is a bug they won’t be trying to blame someone else, instead their pride will make them fix it asap. As I already mentioned previously, encourage your developers to be cross functional whithin the team. The quality of the source code and the SLA compliance of our portal applications have increased significantly after we switched from cross functional teams to component teams responsible for only one product.
7 Take the pressure away from the team
One of the keys to successful scrum is to keep pressure away from the team. In the end you’ll be rewarded with happy team members and top notch quality of your product. The team commits to the scope of the sprint, so do not try to squeeze in more. As the product owner, I am in a different situation – I have many stakeholders who contribute topics to my backlog and who provide budget for the implementation. It sometimes feels like playing Tetris fitting in every little story or even bigger projects into the release planning. Knowing the velocity of your team, it’s capacity (number of person days available during a sprint) and having an estimated and groomed backlog enables you to predict quite well when a story will be released. If you can’t commit to a delivery date, just say no.
8 Peer reviews
One part of our DOD (Definition of Done) is a successful peer review. In this peer review a team member who was not involved in implementing the story tests the result from a customer perspective, checks if the code matches the coding guidelines and makes sure the tests make sense on unit- , integration and UI-level. If necessary bugs are fixed or code is refactored. The quality of our releases has improved significantly after we have introduced peer reviews.
9 Fix bugs asap
Bugs are a pain in the ass for everyone: the customers, the business units, development, operations. Whenever a bug is reported, decide whether it’s super urgent (e.g. when it impacts customers) or not. Urgent bugs need to be fixed quickly and operations should deploy the fix asap. When bugs are taken care of, the rest of the team can focus on finishing the sprint. Automated builds and scripted deployments are key to success.
10 use electronic tools only when necessary
When I started working here in 2009, the backlogs as well as the sprint task boards were organized in Jira/Greenhopper. During the daily scrums a laptop was connected to a beamer, the team members reported what they had achieved the previous day and what they were planning to do today. They even reported hours worked on a task. The scrum master then fiddled around with the mouse, moving digital post-it notes around on the computer. They all hated it. And so we got rid of it. We use Jira for documenting user stories and I use the agile module for prioritizing my backlogs only. The task board is 100% analog and consists of sticky notes on a wall. We use different colours for tasks, bugs, impediments and user stories. The user stories have the JIRA ID on them, so any comments, questions and changes can be documented in the system.
This is my personal view on things of course. Sure enough, not everything we do is done according to the book. But it works well for us and the output of the team is appreciated very much by all the stakeholders. Hopefully you found something here that might help you, too….