Month: April 2017

What’s the What?

Alec Hardy Communication, Developer, Requirements, User Stories

I recently parted ways with my Scrum teams in order to pursue an opportunity another company. One of the team members asked for general feedback about how the team had been doing. Here is my response:

Team,

I have always been open with you about things we are doing well and areas where we need to improve as a team, so instead of specific criticisms or suggestions, let me leave you with a few words of wisdom:

Always ask yourself, “what’s the what?”

Always ask yourself, “why?”

As a technical person, it’s easy to jump to the solution before really understanding the problem. Instead, always strive to understand what user or customer wants and why they want it before deciding how to solve the problem. How is this put into practice? An easy way is via user stories that reflect what the user is trying to accomplish rather than a technical solution. It could be a business task the user is trying to accomplish or a business goal that they are trying to achieve.

The beauty of agile is that you, as technical people, are not only empowered to ask these questions but are expected to. If anyone ever tries to tell you that you should not be concerned about the “what” or the “why”, do not accept that answer. Your users and customers will be much better off when you understand their needs.

Cheers!

Alec

The Product Owner Trap

Alec Hardy Product Owner

My first job as a Product Owner was at a company and industry that were new to me. I enthusiastically embarked upon learning the business, the (very large and complex) products, and getting to know the team and customers. After a few months, things seemed to be going pretty smoothly and my boss asked me to take responsibility as Product Owner on a second team. Challenge accepted! I took it as a sign that I was doing a good job and ready for more responsibility. Now I had two large (7 +/- 2 people) Scrum teams both dealing with unrelated parts of a complex product and implementing unrelated, complex customer needs. Was I learning as deeply about the product and the customers as when I only had one team? Maybe not, but I still felt that I was growing and delivering value.

The mistake that I made was in accepting a third large team, also with a complex problem to solve, unrelated to the work the first two teams were doing. While it was fun to operate at such a fast pace, I started missing daily standups and retrospectives. Sometimes I had to focus on one customer for a few days at the expense of my other teams. In short, I stopped being a good Product Owner. Worse, I relied more on others around me for quick answers to questions about how the (existing, complex) product that we were enhancing worked rather than discovering that for myself thus stunting my learning process. The teams felt as though they were not getting what they needed from their Product Owner.

Eventually I went back to being PO for just two teams. What did I learn about a Product Owner’s maximum capacity?  It’s not as simple as saying that it is a maximum of two or three teams. It may only be one team. It might be three teams. It depends on:

  1. The Product Owner’s level of domain expertise and level of existing product knowledge.
  2. The complexity of the customer’s needs or goals. Complex problems take time and collaboration to figure out.
  3. Whether the different teams are working in the same domain (or in the case of a very large problem domain, are they working on the same aspect/area of the same domain).
  4. Team sizes. Bigger teams usually mean more is completed in each sprint which means more work for the PO before and during sprints.
  5. The Product Owner’s level of expertise at being a Product Owner. If the ceremonies and nuances of working with a team and the customer are still somewhat unfamiliar to the PO, it will take them more time do fulfill basic PO responsibilities.

Reflections:

  • There is no simple rule for determining how many teams a Product Owner can serve at the same time. Look at all of the factors above when deciding how much is too much.