RedAgile

https://www.redagile.com/scrum-guide

https://resources.scrumalliance.org/Article/7-skills-need-great-product-owner

BY SCRUM ALLIANCE image of a product owner helping an agile Scrum team succeed

Scrum is great at defining roles. A product owner, for example, owns the product backlog, creates user stories, and interfaces with stakeholders as well as the Scrum team. That's all true, but what does it take to be a truly effective product owner?

To explore that, we turned to Lowell Lindstrom, a Certified Scrum Trainer® and one of the early pioneers in Agile software development. Over the past 30 years, he has worked with and coached many product owners. In his experience, the people who are best suited to the role thrive on accountability, visibility, and the art of negotiation.

But there are nuances to those particular qualities. According to Lindstrom, the great ones have seven abilities that surpass the generic “Be a good communicator” or “Be available” requirements that could apply to just about any job out there. Spoiler alert: If you hate conflict, this role is not for you.

Related: In Search of the Perfect Product Owner

Customer Delighter As a product owner, you're not just an administrator, taking whatever the stakeholder says and adding it to the product backlog. Sure, you have to listen to what your stakeholders want, but you have to do more than process information — you have to discover those latent needs that your customer or user hasn't even imagined.

Lindstrom, for example, just started using a new email client and was delighted to discover it had a feature allowing him to easily convert an email message to a PDF. No more converting it to Word first or changing the “destination” option within the print function. Clearly, the team that created this feature had thought beyond the usual requirements of email.

Related: Diagnosing Dysfunction Using the Product Backlog

Storyteller Great product owners go beyond the mechanics of chopping up a user story into the product backlog and sending it to developers. As a product owner, your mission is to think about what will transform that story into a product feature that — you guessed it — delights the user.

Let's take another email example. Say a backlog item for a ridesharing company is to provide a receipt to users via email. What is the broader story? Maybe the user is a busy person on the way to the airport, and she needs to create an Excel expense report based on that receipt. If that's the case, you can think of additional information that will be helpful, such as payment method (PayPal or credit card), document options (e.g., PDF), pick-up and drop-off location, distance traveled, etc.

Delegator Let's be honest. Even though only one person is supposed to be the product owner within the Scrum framework, it's almost impossible for a single person to manage everything alone. If things start slipping through the cracks, you start to see teams creating additional parallel roles. For instance, a team may create a technical product owner role to compensate for product owners who don't see themselves as the team leaders.

To survive and thrive, you need to delegate and ideally build an informal team that will help you. Wait, doesn't that sound like the Scrum team? Well, yes and no. The team could include the ScrumMaster and various members of the product development team if you want it to. But it's a separate, informal product owner team that can help you with various responsibilities, especially the ones where you may not be the expert.

Developer It's no mistake to say you're a developer, too. In Scrum, we get hung up on carefully delineating roles. That's helpful for teaching Scrum, but not always as helpful in practice. Roles can become so overstated that the focus moves away from the value being delivered to who does what. As a product owner, you may think, “I own the product backlog. I own the user stories. I give them to the development team, and they develop them.” True, but guess what? You're part of a team. You’re not just a team leader.

It's the entire team that delivers value. If you see yourself as part of the development team, where your responsibility is guiding what should be built, you'll end up with a healthier collaboration.

Knowledge Broker Just as you are a developer, you are also a knowledge broker. Yes, you represent the product backlog and you are the interface between the development team and the stakeholders. But you're not necessarily the definitive expert on the product. So the developers writing the code may not get very far by talking to you to get user story details.

Instead, they should be talking directly to the experts, the stakeholders for the users. Your job should be to enable collaboration and empower the developers by finding the right people for them to talk to. Now, if those discussions bring about changes to the requirements, absolutely, you should be in the loop. If not, put the developers in the driver's seat so they can get the information they need.

Conflict Resolver If you can't handle conflict, you're in the wrong game. In product development in particular, we're dealing with an inherently conflict-filled situation. This is especially true when people are fighting over resources and politicking, as they will do. So the better you are at resolving conflict, the less you will have to escalate (see below).

As a product owner, you have to have the courage and the capability to engage when things get difficult. And know this: you generally have to go through conflict to get to a solution. You'll need to be collaborative to minimize the negative, and you'll need to mediate.

Related: High-Performance Teams — Why the 'Who' Matters Less

Effective Escalator Inevitably, no matter how good you are at resolving conflicts, you'll need to escalate something up the chain of command. This is not about personal squabbles, like little kids whining to Dad, “He hit me.” Escalation is feedback to management that management has deployed conflicting goals. For example, take two stakeholders who have tasked the same team with two different goals that don't fit. That's conflict, plain and simple.

The best product owners have a conflict escalation mechanism ready to go. Of course, you'll try to sort things out as best you can with stakeholders, but you'll also have the cultivate the ability to go up the management chain and back down again. Don't wait until you have a crisis before you build and test your escalation path. Look for opportunities to escalate small (yet applicable) things very quickly so that you get good at this. Then, when the big things come in and the stakes are high, you'll be ready to escalate with ease.

There are many more skills that, as a product owner, you could cultivate to improve how you show up for your team, but working on these seven will give you a leg up on the role. Scrum Alliance Certified Product Owner training and certification may also provide the support and empowerment you need to succeed. Learn more here.

Lowell Lindstrom is the founder of the Oobeya Group, LLC. You can read more about him on his Scrum Alliance profile.

https://resources.scrumalliance.org/Article/in-search-of-the-perfect-product-owner

BY RICHARD K. CHENG Image of product owner coaching an agile Scrum team

\The product owner is a critical role in Scrum. They are the one that translates the needs of the users, customers, and stakeholders into a product vision, roadmap, and backlog that maximizes the value of their product.

However, how do we know if we have the perfect product owner, and what does it even mean to be a perfect product owner? Below are five key attributes to look for in an ideal product owner:

1. Bandwidth
2. Power
3. Knowledge
4. Interest
5. Vision

Bandwidth Bandwidth is best explained via a story. Years ago, I was a ScrumMaster at an organization where the Senior Vice President of Something Important, we’ll call her Jesse, wanted to be our product owner. The Scrum Development Team and I were initially quite excited because we had a great relationship with Jesse, and Jesse was very high up in the organization. With Jesse as our product owner, we felt that we could get a lot accomplished. However, we quickly realized that this was not working as well as we would have liked because Jesse was never around. For example, we were building out a new part of the website and the team needed to meet with Jesse to review some of the needs. Jesse said, “Absolutely. I’m about to get on a plane to New York but I’ll be back in three days. Let’s meet then.” At this point, we set a 45-minute meeting on the day of Jesse’s return, to which she showed up 20 minutes late. All of this is a bandwidth issue. Bandwidth: having enough time and capacity to work with the Scrum team, manage the product, and work with the users, customers, and stakeholders.

There are essentially two ways to resolve this issue:

Free up the product owner’s time so they have more time for product ownership Find a new product owner Related: Becoming a Scrum Alliance Certified Product Owner

Power Since Jesse was so high up in the organization, paring down other parts of her job wasn’t really feasible, so we went with option two: find a new product owner. Jesse had a direct report, David, who Jesse thought could do a great job. So, what if Jesse had approached David and said, “David, I want you to be my proxy product owner. You do all the day-to-day stuff, just make sure to run all decisions through me.” If we had gone down that route, not only would we not have addressed the original issue, but we would have made it worse by adding yet another layer into this product ownership. So, Jesse did not do that, but Jesse approached David and said:

“David, I’d like to talk to you about being the product owner. Your product, your team. As long as you’re aligned with the product vision and roadmap, you run with it. I’ll take a step back and be more of product champion or product sponsor and we’ll periodically synch up to make sure we’re aligned.”

This is power: the authority to manage the stakeholder needs, order and refine the product backlog and product needs, and the ability to accept the product increments. Whenever we hear terms like proxy product owner, delegate product owner, de-facto product owner, vendor product owner, stand-in product owner, analyst/product owner, or any variations such as those, we begin to wonder if they really have the power to be an effective product owner.

Knowledge What if David was a brand-new hire to the organization and had no idea about the product? That certainly would have been a big risk. Fortunately, David had been with the organization for more than six years on the business side and had a deep understanding of the product. That is knowledge: having a deep understanding of the product, who the users and stakeholders are, what they find valuable, and what the organization’s goals are for the product.

Interest Suppose David said, “I don’t want to do this job, I’m not interested!” Yet, he was forced to do the job - how well would that work? You would essentially have a disinterested absentee product owner. David would say things like, “I don’t have time to go to this meeting, you guys figure it out,” “It’s all high priority, get it all done,” and “I don’t have time to review it now, just show it to me at the end.” However, in this case, David was very excited about being the product owner and to work with the team rolling out this product. Interest: having a strong desire to be the product owner and being able to maximize the value of the product.

Vision What if the team approached David trying to understand the goals of our releases and David said, “I don’t know, where do you think the product should be going?” That is not product ownership. In this case, David had a strong vision for the product and was very excited about bringing this vision to the users. David was so excited and engaged with the vision that he was able to get the team excited and engaged with the vision, and an engaged team produces a better product. Vision: having a great understanding of what the product is, where it should be going, and the goals for the product.

The Perfect Product Owner Thus, the five key attributes to seek in a product owner are:

• Bandwidth: Having enough time to work with the Scrum team, manage the product, and work with the users, customers, and stakeholders.
• Power: Having the authority to manage the stakeholder needs, order and refine the product backlog and product needs, and the ability to accept the product increments.
• Knowledge: Having a deep understanding of the product, who the users and stakeholders are, what they find valuable, and what the organization’s goals are for the product.
• Interest: Having a strong desire to be the product owner and being able to maximize the value of the product.

Vision: Having a great understanding of what the product is, where it should be going, and the goals for the product.

Richard K Cheng is a Scrum Alliance Certified Scrum Trainer and the VP of Training and Chief Product Owner for NextUp Solutions, where he can be reached at richard.cheng@NextUpSolutions.com.

https://resources.scrumalliance.org/Article/adopting-tiramisu-mindset-build-product

BY VALERIO ZANINI

The Tiramisu is one of the most famous Italian desserts around the world. Walk into an Italian restaurant, and more likely than not they offer it. Travel throughout Italy, and you can find it everywhere. Originally from the north-east region of Veneto (where Venice is located), the Tiramisu has become eponymous with Italian dessert. And if you Google it, you can find a variety of recipes to make your own.

Yet, making a good Tiramisu is not an easy task. There are three main ingredients in a Tiramisu: espresso coffee, mascarpone cheese, and ladyfinger biscuits. These three ingredients need to be in balance for the Tiramisu to come out good. If you put in too much coffee, too much cheese, or too many biscuits, you may end up with a dessert that resembles a Tiramisu but in fact is too soggy, too mushy, or too dry.

When I look at the Product Manager/Product Owner role, I find that a similar balance exists. The Product Owner has three main responsibilities, which I define as:

Understand the customer, the problem, the market Drive product development and build the solution with the Development Team Measure the outcomes and validate the solution to the problem In working with teams around the world, I have often seen that only one of these areas is kept in focus, while the others are barely touched. Often, Product Owners spend some time understanding the customers, and then quickly jump to a solution and focus on building it. Measuring the outcomes comes at the end of the development process, and often as an after-thought rather than being an integral part of the process.

Yes, the team may adopt Scrum and do “Agile”. But when the three responsibilities are not kept in balance, Scrum becomes just a method to execute the work, and the team focuses on the execution part. It may build the product in Sprints, but the overall product development looks like a long cycle before it’s validated in the market.

Adopting a Tiramisu mindset helps to build products in rapid iterations, maintaining the focus on what customers need, and measuring outcomes along the way, as the product gets built.

In this article, I’d like to answer a few questions that came up when I presented the topic to the Scrum Alliance community. These points are useful in thinking about how to support a Tiramisu mindset and avoid falling into the “build trap” of focusing on execution alone.

How can we get a Product Management and Innovation Assessment?

Change and improvement often starts from awareness, about the skills and knowledge that we don’t have, and about the desire to develop them. There are many ways to develop awareness, including reading articles in this community, participating in conferences, reading books on the topic, and more.

One valuable method is to use an assessment tool that can quickly help you understand key areas where you may not have the full skill set and that you may want to develop further.

We have built a Product Management and Innovation Assessment tool for this purpose; it's available through Comparative Agility. This assessment can be used by individual Product Owners, by teams, or by the larger organization, and it provides insights on which areas you may focus on as you develop your expertise in Product Management and in driving Product Innovation.

In a tech-strong world, how come you still chose to create a journey map on a wall? With our new reality of working from home, how would you run these workshops virtually… with no sticky notes, no paper, no pens and no walls?

Whenever I can, I prefer to use sticky notes and whiteboards to generate ideas and collaborate with others, rather than writing on a computer. My house is full of sticky notes and multiple whiteboards for this reason. They help me visualize things better.

However, the world is quickly changing. Even before the Covid-19 pandemic, teams were already starting to go remote - if not being remote altogether. The recent months have just put more pressure on everybody to figure out how to work collaboratively even when we are socially distanced.

Many tools exist to support this way of working, and one of my favorites is Miro. It’s a virtual whiteboard where you can create stickies and frameworks of all kinds, while collaborating with team members around the world. I’ve used it for product planning, for ideation sessions, and for running training classes with my students, with people simultaneously working together from the USA, from Germany, from Pakistan, and from Columbia.

There are many other tools like it (Mural, Span Workspace, Google Jamboard, etc.) and everyone has their personal preference. In the end, it’s about creating a space when team members come together and share ideas.

With going remote, the business has been forced to utilize more technology. How do we deal with the gap? Sometimes they are hesitant to learn new Agile tools like Mural / Azure DevOps / JIRA?

In situations like these I often go back to the basics. In this case, the agile value of “Individuals and interactions over processes and tools”. Tools are great, and certainly they help solve many problems - especially in letting us feel connected even when we are physically separated from each other. At the end of the day, it’s not about the tool itself, it’s about fostering a culture of collaboration and communication between the individuals that work together.

Let’s take an example. Sometimes I hear teams become restricted by Jira. Everything is in Jira. All the details should be written in the User Stories. People are criticized for not being specific enough. If it’s not in Jira, it won’t get done. And so on. The “tool” becomes the controller of the team.

Every tool has its pros and cons, and Jira is no different. While powerful and simple enough to use, it forces teams to think within its constructs and allows (like most tools) little flexibility. For example, it forces teams to look at work as tasks that individuals need to complete, rather than creating a sense of team and self-organization that empowers team members to work together.

I often say to my teams, having the details written in Jira is great, but don’t forget to share and communicate with each other. As much as you can write details in a card, there is always something left out or a possibility for mis-interpretation. So creating the space for collaboration and alignment is essential. At that point, which tool you are using to save the details becomes irrelevant or a choice of convenience.

How important is it that the customer understands the agile mindset and process, in order to work with an agile team on an MVP?

I think it’s essential to have customers understand the agile mindset. It’s not about them becoming experts in Scrum. It’s about them supporting the team in the product development journey by being accessible and available, by providing frequent feedback, by allowing for plans to change.

The goal of adopting agile practices is to reduce risk, maximize the value of the product delivered, and reduce the time to market. What customer would not like any of these?

In order for the product team to be effective at achieving these objectives though, the customers play a key role. They provide context about the problem they need to solve and why that’s important. They provide feedback and validation along the way, to help the team steer the solution towards a product that works and solves the problem. And they understand that having an upfront plan with all the requirements fully scoped out may not be in the best interest of risk reduction or value delivery. Therefore, they support the team in creating plans and changing the plans at any time as they learn more.

Is there a limit to the number of MVPs you can have on a product?

The short answer is, there is no limit. You may have multiple hypotheses, and you may want to deliver different MVPs or different versions of your MVP to validate these hypotheses.

It comes down to the purpose of an MVP. I think of the MVP as a tool that Product Owners have at their disposal to quickly validate hypotheses and reduce the risk of building the wrong thing. At its essence, the MVP should help to validate (or maybe invalidate) a key hypothesis you are making about your solution, your customer behavior, or your market. You build a “minimum” product that you can put in market, in the hands of your customers, to test for “viability”.

Is this working? Would customers use it? Does it validate our hypothesis?

If it works, you move on to the next step. If it doesn’t, you may pivot, consider a different solution, and deliver another MVP to validate again your hypothesis until you find something that works.

One good tool to use is the MVP Canvas. The MVP Canvas helps to define the hypothesis and create alignment of the metrics to use to measure it.

A new project is created and the MVP is clear, but only the stories for the first one or two Sprints are created. The customer wants to know when the MVP will be ready. Is it good practice to dedicate the team to creating all the stories at high-level and provide a high-level estimation? How does the Tiramisu method help with release planning for those customers/managers that want a release plan and a forecast for what can be delivered when?

I think it comes down to the agile value of “Adapting to change over following a plan”. Having a plan is great, and in fact agile practices support many ways of planning, across a variety of horizons. While short-term plans can be quite detailed and specific (e.g. a Sprint Backlog for what the team is working on in this Sprint), longer-term plans are less specific because everyone understands that they may change as the team learns more and new ideas emerge for the product.

One way to address the planning of an MVP and create shared understanding with customers and stakeholders is to use a Product Journey Map. This is a great tool that helps the team plan an MVP and create transparency on what is in the MVP and what is not. And it allows for the team and its stakeholders to align on any changes.

Building a Product Journey Map is an exercise that can be done collaboratively to create shared understanding and transparency on the plan. To learn more about this tool, you can refer to this article and also download the PDF worksheet that guides you on the process.

The key to making a Product Journey Map workable is to avoid getting bogged down in too much detail upfront. I like to start doing it at the “Feature” level rather than using User Stories.

To answer the question about delivery date, you need to have an estimate of the amount of work, and a measure of velocity (how much work you can do in a given unit of time). So once you have built your Product Journey Map and identified your MVP, estimate the amount of work needed for it, and derive an estimated timeframe.

Everyone should understand that the estimated timeframe is exactly that, “estimated”. At this stage we can only guess when we’ll be able to deliver it, and things may change as we do the work.

In order to create transparency with the stakeholders, you can use a Release Burndown tool, tracking the progress on your product at each Sprint and projecting out the time to completion.

By having transparency at every stage of the project, you can have conversations with stakeholders when the plan does not align with the expectations. And at that point, you can discuss adjustments to the timeframe, to the scope of the project, or to the number of teams. The Product Journey Map is a great tool to support these conversations and create transparency on the plans.

Learn more from Valerio by watching his Scrum Alliance webinar Adopting a Tiramisu Mindset to Rapidly Build Products and Deliver Value.

Valerio Zanini is a Certified Scrum Trainer, a SAFe Program Consultant, and a Certified Product Innovation Trainer. He is passionate about creating products that customers love and developing the teams that make them a reality. He has two decades of product development experience in a variety of organizations. He is the author of Deliver Great Products That Customers Love and the founder of Spark Engine, a training, and certification program in Product Innovation.