Pete Deemer needs no introduction among the Agile software community. A key member of the Scrum Alliance who served as its chairperson in 2017, Pete has over 25 years of experience in guiding product development teams. He is the lead author of ‘The Distributed Scrum Primer’, a guide to multi-location Scrum and ‘The Scrum Primer’, one of the most widely read introductions to Agile development. Pete shared some insights and lessons from 20 years of product ownership with us recently, and here are some key takeaways:
How to speed up a development team
Asking a development team to simply work harder and faster, while giving them words of encouragement does not have a lasting impact. As the pressure increases and the team works longer hours, although output may increase for a while, burnout sets in soon after. Recovering from this is extremely difficult – quality reduces drastically while output rarely goes back to the same level it was.
When a programmer rushes, they make more mistakes. When a tester rushes, they find fewer mistakes.
Smart product owners therefore should identify ways in which to increase output without the risk of burnout. They can do this using the Agile methodology ‘Lean’: improve efficiency by eliminating waste. A key part of this is to reduce impediments. Pete defines an impediment as ‘anything that gets in our way, interrupts us, distracts us, causes mistakes, creates rework, causes waste, hurts our motivation or stops us from being as good as we can be’.
Identifying any and all impediments that the team has or foresees as early as possible, and figuring out how to navigate them or reduce them is greatly beneficial to the overall productivity of the team. It allows output to increase and stay at a high level for longer periods. Teams work the same hours but at a more sustainable pace, and are therefore less exhausted as they encounter fewer hurdles. Additionally, the work the team produces is often of high quality in this situation. It’s important that product owners create an environment of openness for the team to express themselves and be honest about all impediments they have – even if certain impediments are caused by the product owners themselves!
How to handle new requirements or – half of what you think you want, you don’t need, and a lot of what you actually need, you haven’t thought of yet!
A fundamental reality of product ownership is not knowing exactly which direction a product is heading. It is therefore vital to be able to adjust and change the sails and change course without causing disruption or panic.
During a Scrum Kickoff, the product owner identifies the product goal and creates a product backlog that consists of features or stories – things of direct value to customers or users. These are known as product backlog items (PBIs). PBIs are then broken down to smaller features, and organized into sprints to work towards the final release. However, a product owner may think of a brilliant idea for a new feature that will greatly enhance the product halfway through product development. Simply adding this new feature in without making any adjustments to the existing PBIs will cause a delay and disrupt the process as the overall product backlog increases.
There are four key factors that come into play when thinking about products – scope, schedule, cost and quality. These are interlinked, and a change in one aspect often results in a change in one or more of the others. Eg: If the product owner tries to increase the scope but not adjust the schedule and cost, the quality may see a drop.
It is important to note that, if the product owner and team do not willingly change each factor to reflect changes in the others, the changes may occur in unplanned and unexpected ways. This will often have a negative impact on the overall progress of the product.
Therefore, to make allowances for new PBIs, the best option is to find PBIs or features that are of lower value and replace those with the new features. The overall scope stays the same as it is being balanced, and the value of the product increases (as your new addition is likely of higher value than the PBIs that were removed).
Flexibility is key in good product ownership and Pete reiterates that ‘we have not had our best ideas yet. Our best ideas are still to come. And we need to be prepared to respond to that.’
You don’t pick when your good ideas come. They come when they’re ready to come.
How to structure a product backlog
To be able to remove and replace PBIs, it is important to realistically evaluate the true value of each. Sorting PBIs by priority and value allows room for any adjustments to be made – such as if the team finds they need more time to fix a high value feature, or the product owner needs to add a new feature halfway through. This also allows the team to make any adjustments based on user feedback from beta testing. Similarly, if due to some reason the release date has been reached but some PBIs are incomplete, it will have only a minor effect on the overall value of the product as the items left out are of relatively low-value.
Pete recommends having a ‘Scope Buffer’– PBIs that can be dropped, or postponed to a later release. This way, even if they remain incomplete by the release, a high-value product can still be delivered without delay. The ‘MoSCoW prioritization’ can help product owners prioritize their PBIs. It groups PBIs into the following categories – ‘Must have’, ‘Should have’, ‘Could have’ and
‘Won’t have’. ‘Must have’ items should be placed high on the PBI list, followed by ‘Should have’, ‘Could have’ and finally, ‘Won’t have’ items. This method ensures that no matter what, a minimum viable product can be created within the planned time frame.
One certain thing product owners should know – things won’t go as planned!
How to work effectively with remote teams
Establishing connections with people you haven’t met, and who are in a geographically separate location is not easy. However, with remote work becoming the norm, there are ways to navigate some of the oft-encountered barriers. Pete believes that trust is what enables a product owner to get the most out of a team.
Trust is a force multiplier
In a low-trust environment, developers don’t ask questions, hide mistakes, ignore concerns, cover up problems, and pretend all is well until it is too late. However, in a high trust environment, developers are open and honest – questions are asked, thus fewer mistakes are made, and concerns are brought up, ensuring that problems get tackled early. An environment that promotes trust and values honesty (even if that honesty brings up things the product owner doesn’t like to hear!) is vital when working with remote teams.
Some ways through which trust can be built:
- Establishing real, human relationships at the start: Pete encourages any product owner to take the extra time, spend the money and meet the development team at least once at the beginning of a partnership. This helps the team see the product owner as a real person, and helps establish a connection between all parties. If it is not possible to physically visit the team, engaging in online icebreakers and team activities that encourage people to share information about themselves, their interests outside of work etc. help to promote the relationship between product owners and their teams.
- Understand the inherent power differential: There will always be a difference in power dynamics between the team and the product owner, and it is important for product owners to be aware of this when working with the team.
- Show respect, and reward honesty
- Be mindful of language and communication barriers and biases: Establishing a common language for communication is important but it is equally important to be aware of the biases that come through the use of a language – such as English- that may not be the first language of either the team or the product owner. A key fact to remember is that proficiency of language is not an indicator of professional capability.
- Agree on the ‘rules of the game’ and play by the rules: Eg. A product owner should not ask developers to be honest and then penalize them for their honesty.
- Scale the communication and be aware of signal-to-noise: One of the main problems encountered by product owners and teams is miscommunication. Depending on how sensitive the matter is, the most suitable method of communication should be utilized. Eg: A text is alright for a quick clarification but an email would provide greater detail, while an audio call or video call would be the most preferable for a longer back and forth discussion. In-person meetings are the best choice for any high priority communication, as richness and fidelity is highest in this instance. It is up to the team and the product owner to determine the best method of communication for the circumstance.
Successful products don’t teach you anything, it’s the failures that do!
Building an exceptional and valuable product is no easy feat—both product owners and development teams have a responsibility to each other. Pete hopes that by sharing lessons learnt and knowledge acquired, he may help others avoid pitfalls while incorporating practices that benefit the team and product owners alike.
Also, if you want to learn more about how to build great software and digital products using a remote team, go check out our Remote Team Playbook. A complete recording of Pete’s webinar is available here.