Product Owner Dependability and Adaptability
This blog post is an invite for open discussion. If you have any insight or opinions about the content included in this post, please feel free to comment. We appreciate all feedback and welcome all input.
Here begins Rev 0 AKA the rough draft of my efforts to produce a concise and valuable summary of being a dependable, yet adaptable Product Owner using my experience on Team WIKISPEED as an example.
Team WIKISPEED is a United States registered automotive manufacturer run entirely by volunteers, with a goal to develop a 100+ MPG equivalent, open source, modular automobile using the Scrum framework and Agile design principles. As of this writing, Team WIKISPEED is made up of 5000 members distributed throughout 50 countries in individual shops, garages, sheds, and sometimes even spare bedrooms.
Chris Wallace is the Product Owner of the WIKISPEED Burleson, TX, USA shop where the local team is currently leveraging Scrum to improve an open source, ultra-lightweight, automotive chassis design for the WIKISPEED SGT01 prototype. Specifically, the priority focus is innovating a simple, bolt together chassis assembly which can be replicated anywhere in the world with basic tools, rudimentary skills, and locally available materials.
As Product Owner of a WIKISPEED shop, I need to constantly adapt to new and often unexpected situations. The Burleson shop has one scheduled Build Party per week. During each weekly Build Party, the team members may be completely different. Some volunteers may be here for the first time. Some have never before heard of the Scrum framework or Agile methodologies. Many have never worked in a machine shop or even on their own cars. At the beginning of each build party, I meet everyone and ask what brings them to the shop. After everyone has given a brief introduction, I say the elevator pitch for the features of the finished minimum viable product for this release cycle. Then I prioritize the Product Backlog based on the interests of the present team members. From that prioritized Product Backlog, the team estimates and pulls stories into the Sprint Backlog for that Build Party.
Often times, there is no experienced Scrum Master at the builds. In these cases I will ask for a volunteer to be Scrum Master with the main goal of removing blocks for other team members. I will then take the responsibility of coaching and clarifying the Scrum framework and how we use it to maximize the awesome. This strategy has facilitated us being adaptable to change while still meeting the expectations of the stakeholders.
To demo our progress to the stakeholders involved, the need to adapt becomes very apparent. We use 7 day Sprint cycles and have a demo during the WIKISPEED MetaScrum (Scrum of Scrums) every Thursday via Google Hangouts. This is when I present our progress and get feedback from the stakeholders and international team. It is not uncommon for the feedback received to change the goals and priorities of the next Sprint. As a Product Owner if you are not comfortable constantly adapting to change, you and your team will spend a lot of time working on goals that are of little or no value. This pitfall goes against the very purpose of the Scrum framework.
Besides the weekly scheduled Build Party the shop is available 24 hrs a day to anyone who has signed the “Join the Team” form, www.WIKISPEED.org/join-the-team. To be dependable and effective as the Product Owner, I have to be available to answer questions, explain expectations, and clarify the acceptance criteria. One thing I always do, in case someone comes to the shop when I am not there, is prioritize the Product Backlog at the end of each Build Party. If someone shows up, they should be able to look at the Scrum Board and get a good idea of what the next priority is. I also give out my cell phone number and email address freely to everyone on the team and invite them to call, text, or email me anytime. I add this information to my email signature and reiterate the invitation every time we meet in person. When I am in the shop, I also am a member of the build team. However, no matter what I am currently working on, I will stop to address any of the responsibilities of a Product Owner to not be a block or bottleneck for others on the team.
Because of the dynamic nature of the build teams being made up of volunteers, it can be a real challenge to predict what may happen from week to week. Occasionally, for one week’s Sprint, very little progress is made because we don’t get the expected turnout at the shop and do not have enough people to form a Scrum team. Even in these instances, I still attend the Weekly MetaScrum because an update is expected even if it’s just an explanation of the drop in velocity and a plan to improve the velocity and focus on the most valuable features for the following week. This allows me to keep the work visible for the stakeholders and other distributed teams. As an added benefit, the other team members often cheer you on and offer advice for improving velocity and team morale.