Product Owner - Agile and Scrum Blog

Agile Teams, Conflicts, and TKI

In the world of agile, conflicts are natural part of the team’s journey towards innovation and efficiency. When teams come together to work towards a common goal, they’re bound to have different ideas and opinions. Facilitation is a great tool to help navigate through healthy conflicts. That’s one reason why having a ScrumMaster is always useful. But here I wrote about this many times already. This time I want to introduce a tool that is not that common, but is very useful to have in your ScrumMaster toolbox. Thomas-Kilmann Conflict Mode Instrument (TKI) is a tool, that helps people understand how they handle conflicts and keep your team productive and happy. It identifies five different conflict-handling modes:

Competing

The Competing mode is in the assertive and uncooperative quadrant. Sometimes, making important decisions without the team’s agreement can damage trust and cause problems. For instance, a Product Owner makes sudden changes without talking to the team, which leads to anger and quality issues. Or a team member pushes their ideas without listening to others, which breaks up the work and creates tension. On the other hand, it’s okay to make quick decisions when you really need to. For example, a Scrum Master can quickly stop a discussion to make sure the team meets a goal, or a developer can say that security is important, even if others are more focused on velocity.

Collaborating

The Collaborating mode is in the assertive and cooperative quadrant. Sometimes, trying to get everyone to agree can slow things down and make teams less efficient. For instance, if you spend too much time brainstorming and trying to please everyone, it can delay decisions and cause a condition called “analysis paralysis.” Or, if you try to include everyone’s opinions, it can expand the scope of the project beyond what’s actually needed. On the other hand, this mode is great for bringing together different perspectives and building consensus when a team works together to make sure technical decisions align with business goals. This can improve product delivery and customer satisfaction, or when developers and the Product Owner collaborate to make sure user stories are clear and prioritized correctly.

Compromising

The Compromising mode is intermediate in both the assertiveness and cooperativeness quadrants. Sometimes, accepting partial solutions can lead to missed opportunities for achieving the best results. For instance, when the team agrees on a solution that partially satisfies everyone but fails to fully meet important technical or business needs, or when sacrificing test coverage to meet a sprint goal, causing later rework and technical debt. On the other hand, it can be useful for achieving temporary settlements like negotiating a minimal viable feature set with stakeholders to meet release deadlines or splitting time between refactoring and delivering new features to balance technical health and value delivery.

Avoiding

The Avoiding mode is in the unassertive and uncooperative quadrant. Sometimes, ignoring recurring problems can make things worse, and it can hurt how well the team works together. For instance, if the team keeps ignoring the same issues, it can lead to technical debt or if a Scrum Master avoids dealing with conflicts, the team can keep getting stuck. But there are times when it’s okay to ignore small problems or when others on the team are better suited to handle certain conflicts. For example, if there’s a non-essential process debate that can wait until the retrospective, or if a developer with deep expertise can handle a minor technical disagreement without involving the whole team.

Accommodating

Finally the Accommodating mode is in the unassertive and cooperative quadrant. Sometimes, trying to please everyone too much can lead to forgetting about important things like technical and delivery needs. For instance, if a developer keeps agreeing to impossible deadlines to keep everyone happy, it can cause burnout, or the team always puts stakeholder demands first, even if it means ignoring technical debt. On the other hand, sometimes it’s good to keep harmony and relationships in the first place. For example, agreeing to small feature requests to build goodwill with stakeholders or when a senior developer lets a junior team member lead a task to gain experience.

Agile teams are all about teamwork, and it’s important for everyone to know how they usually deal with conflicts and how leaning towards different modes can change the team dynamics. For example, if you have a ScrumMaster who is very strong on Avoiding and Accommodating, they might ignore team issues, fail to remove impediments, and compromising agile principles to keep everyone happy for a while. In a nutshell, they’re not really helping teams and organizations change. Great ScrumMasters need to have a balanced profile with high Collaborating to integrate team insights and fostering consensus, and moderate Competing and Compromising to protect the team, keep agile principles, and navigate trade-offs effectively.

In real life, people have a mix of tendencies. For example, imagine you have a Product Owner who is very strong on Collaborating and Accommodating. He will cooperate well with the customers and build great relationships which is awesome but at the same time, they try to make everyone happy and can’t set a clear direction or make a decision when needed.

So how to start? Encourage team members to take the TKI assessment to gain insights into their default conflict styles. Understanding one’s natural tendencies can help individuals consciously choose the most effective approach in various situations.

After that, I usually run a workshop to discuss the five conflict-handling modes and explore scenarios where each mode might be most effective. Using role-playing helps team members practice switching modes and understand the perspectives of others.

Great Scrum Masters are a great help. They are good at recognizing conflict modes and are able to help teams find the most constructive way to deal with conflicts. They coach individuals to reflect on their tendencies and help them to create a better balance. They’re the ones who make sure everyone feels safe to share their thoughts, and they step in when things start to get too heated.

Backlog is not a Linear List

“It’s all about Product Backlog. Product Owner should manage it. Prioritize it. Fill it with User Stories.” Sounds familiar? It’s typical at certain stage of agile transformation to focus on building a Product Backlog. And use Jira for that. You find such linear to-do lists in almost every organization at the beginning of their agile journey. And though Product Backlog is very important tool as it brings clarity and align people around the same business goals, it’s also one of the most misunderstood and misused tools. It often starts with a good intention, Product Owner asking customer what they want. And they, in a good intention, brainstorm all the possible functionalities you can imagine. And the Backlog/scope keeps growing while the time expectations stay the same. That’s very common start of a big disappointment with Agile. “It didn’t help us. It’s not faster!” people say, and they are right. Agile is not the way how to deliver more functionality faster. Quite the opposite. It’s a way how to achieve higher business value faster, and those are two different things.

So, if you want to get more business value, start with the backlog. But this time, you’re not asking what you want to be implemented but instead ask for needs and look for a minimal functionality to be implemented to satisfy those needs. 80% of the value is in 20% of the functionality and that’s exactly what good Product Backlog should identify. The higher value items first, the rest later or never.

Good Product Backlog is co-created in collaboration with customer, stakeholders, and team members. They all need to uncover the business needs. They all need to develop an empathy for the customers. In most of the cases Product Backlog they create together is not a linear list that would fit traditional tools like Jira or Excel, instead very often we use Story Mapping technique to create multidimensional maps, or impact mapping technique to create a mind map, or visualize the product as a tree and prune the branches. Nothing that would look like a linear to do list. All the techniques have one thing in common; they focus on the business value and the customer needs. They don’t describe the solution. The how in Scrum should be uncovered during the Sprint in team collaboration. So, forget on the requirements, stop asking your customers what they want, and instead focus on uncovering their needs and together visualize the value in your Product Backlog.

Becoming a Great Product Owner

Companies often ask me how to find a good Product Owner. To start with, great Product Owners need to have a good business knowledge. It’s not about the product feature knowledge that much as your developers will have it as well, but it’s about understanding the overall business and market dynamics, the competitors, the existing product on the market. It’s about being able to create a business plan, understanding the customer needs. Product Owners need to have a sense of how we bring our product to the market. And finally, it’s also about being open to hear the feedback from the customers and change our plans accordingly.

The second area is about having a time to focus on being a great Product Owner. It needs to become your personal goal, so don’t combine it with anything else. After all, your ultimate job is to make the product successful so don’t worry, it will pay back. It takes time to develop different ways of creating Backlog items, it takes time to prioritize, but more importantly you need to have time to collaborate with people. Not only just with your developers, but more importantly with stakeholders and customers. In the traditional environments, we often believe that a Product Owner is a magical person who writes requirements, then throws them across the wall to developers to create and that’s it. But in reality when they catch it, they usually throw it back and say, “We don’t understand this, somebody should give us more details”. But that’s how it should never look like in agile space. Building a Backlog is about collaboration and co-creation with developers, stakeholders and customers. So you should never write backlog items without them. By collaborating and co-creating, people build the same understanding, alignment, and relationships among each other so then when they work on a particular item during the Sprint, they can actually be much more efficient. They ask clarifying questions directly, they don’t need a Product Owner to be in the middle. Having said so, the Product Owner could be seen more as a facilitative role, as a person who puts everybody together, who makes sure they can collaborate, who makes sure they all are aligned and share the same vision, who sets the priorities, who sets the product goals to be achieved, but actually who is not the team assistant that writes requirements. The power of Scrum is in creating teams that are close to the customer and understand their needs.

The next area for great Product Owners to be able to make a decision, be able to say “NO” to a feature. Product Owners who are weak in this and saying yes to every idea your stakeholders and customers come up with are not really good ones because their backlog keeps growing into unlimited size. And by the way, the more collaborative and inclusive you are as a team the worst it goes. So the most important thing Product Owners need to learn is to say “No, we are not going to do that now”. In order to say that you need to have a clear version, clear direction, good understanding of the customer need and market dynamics. 80% of the business value is only in 20% of functionality. Once you accept that, it’s relatively simple to say “We are going to do this now and the rest later or never.” And that’s quite a magical phrase. That’s how you really recognize if being a Product Owner is for you. Because if you can say that sentence with a big smile on your face, you are going to be a great Product Owner, if not, and if it’s only causing you frustration and pain, because you believe that everything needs to be done, the Product Owner role is not for you.

To summarize, you need strong business knowledge, authority and time, plus good negotiation, communication and facilitation skills. It’s a lot, but that’s the mix you need to develop to become a great Product Owner.

The Power of Metaphors

One of the tools I have started using more over the years is a metaphor. Many years ago I was taught the Speed Boat retrospective and tried it with teams. It brought great energy and fun, it helped us to uncover different perspectives. But it never occurred to me that I should take the idea to the next level and use it in other situations. So let’s have a look at different situations where metaphor can be useful.

Organizations are often used to look at outputs, measure effort, and compare velocity. One of the shifts that need to happen is from functionality to business value or in other words from output to outcome. And it’s not an easy shift, especially when the organization is still project-oriented, running on the “fixed scope” mindset. One of the reasons I’m using the metaphor with Product Owners is to shake with their business as usual – we deliver requirements – and reset their thinking about the product. I’m leveraging the Three levels of Reality concept I learned from ORSC and guiding them through the Sentient Essence level by exploring a metaphor, through the Dreaming level where the most collaboration at Backlog refinement is happening, to the Consensus Reality level they are used to by setting goals and objectives. The Sentient Essence level is about feelings it’s the spirit of things. It’s where the purpose is born. And the purpose is often forgotten in traditional organizations.

Using a metaphor is also a great icebreaker and team building. You see how different people collaborate, how they react to different perspectives, and look for commonalities. It can help teams to create an identity and become a better team together.

It’s also a great tool for ScrumMasters to reflect on where they like to have the team or the entire organization in six months, a year, or three years.

I’m often starting by letting individuals draw some animal, real or imaginary. Depending on the situation I might help them explore that metaphor more to uncover different aspects of it. Drawing is just one way how to visualize the metaphor. You can ask people to describe it, to create a gesture, song, or dance. There are no limits.

For example “We are like a flock of birds, they can fly fast, but not for long. Some got tired quickly and started falling down but the others continued without noticing. They are strong, they have great eyes, but once they start the journey they don’t like to change the direction.”

Then we compare the individual drawings, looking for similarities and uncovering the differences. And start integrating different perspectives into a coherent picture. It’s different than talking about numbers, goals, and objectives. It brings energy and creativity and I would encourage you to try it. Let me know how it worked for you.

Failing Fast

To my huge surprise, I realized that the concept of failing fast and learning from failure is difficult for some people to accept. They always feel the frustration when I say that ScrumMaster needs to feel comfortable to let the team fail so they can learn. I wrote about it here a few times, so you most likely know it, but the goal of a ScrumMaster is to make teams self-organized. They are not their assistant nor their mothers (as it might end by being dependent on a ScrumMaster), they are not their managers (the team is self-organized, fully responsible for their decisions), ScrumMaster is a coach, facilitator, helping the team to take ownership and realize they can solve most of their problems by themselves. And with every decision you take, there is a responsibility going hand in hand, and risk that you might fail. It is OK to fail if you learn from it. So ScrumMasters are not responsible for preventing failure, but for making sure the team will learn from it and figure out how are they going to work differently next time, so it will never happen again. And that’s very different from what the project managers have in their job description. And here is why – Project Manager is responsible for making decisions, ScrumMasters is not. It’s either the Development team (for how are they going to organize themselves to maximize the value towards the Sprint Goal), or Product Owner (for maximizing the value, prioritizing the backlog, and achieving the overall product success including the return on investment).

Agile is about safety to experiment and learning from feedback. In the VUVCA world, you never know what is the right functionality which will multiply the value and success. You need to inspect and adapt. Learn from failures. Be ready to respond to changes and be flexible to shift the direction based on feedback. Scrum has it all. Short Sprints which make it safe to fail, Retrospectives which ensure fast learning, Sprint Reviews which create a platform for frequent customer feedback, and Product Owners who take care of maximizing value and return on investment. It’s one thing to read it, and another to live it. What happens in your body if you hear “Your Sprint just failed.” Is it closer to the panic and looking for who to blame or is it closer to being curious and excited to search for improvements? It’s a simple question that indicates the level of agility. Failure is a good thing. All you need to do is learn from it.

New Scrum Guide

There was a new version of ScrumGuide published last week. And I have to say that I mostly like it. It’s lighter, less prescriptive, and simple. Here are a few differences.

#1 – Scrum Guide 2020 is Simple and Clear

Scrum Guide 2020 is clearer. Finally, there is a sentence that is easy to read, and that describes what Scrum is:

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

A Product Owner orders the work for a complex problem into a Product Backlog.

The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

Repeat

Scrum is simple.

Yes, Scrum is simple and so the Scum Guide. It’s easy to read and understand. With this version, we got rid of many long and complicated phrases full of details. For example, one of my favorite changes in this space is that daily Scrum finally not suggesting the three questions but recommend that people “can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal…” Isn’t that awesome? After all those years of individual status meetings where people were reporting to someone what they did. It’s finally gone!

#2 – Focusing on the Mindset

I like the fact that the new Scrum Guide stresses the three empirical pillars of transparency, inspection, and adaptation and explains what are they about. The five values of Commitment, Focus, Openness, Respect, and Courage are clearly defined there now as well. It focuses on people’s behavior, over the processes and practices.

I also like the new Scrum Guide to remind us about the primary need for Agile and Scrum in complex and unpredictable environments: “In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” All over, if you know what needs to be done, can plan it, then all you need to focus on is how fast are you going to deliver it. In such a world all different estimation techniques, velocity, burn-down, and burn-up charts are considered useful. Unlike Scrum, which builds on empiricism and inspects and adapts the plans on the way.

#3 – Scrum Team Focus

The biggest change seems to be that we don’t have “Development Team”, ScrumMaster, and Product Owner but “Developers”, ScrumMaster, and Product Owner forming a Scrum Team together. It looks like a big change, but it’s rather cosmetic as they all have to collaborate and self-organize (or self-manage if you like) to maximize value towards the Sprint and Product Goal. So, no real change there, we’ve just finally got rid of the very typical dysfunction where the Product Owner was like an enemy and the team was delivering to the Product Owner only. Now there is no such mentality in the Scrum team, they are in it together, responsible for all product-related activities. They are a team in the first place, a team that is cross-functional so can deliver end-to-end value together. ‘Developers’ is a poor name, as most people somehow read it as software developers but it’s more like a product workers. They are still the people who create working product increment every Sprint, while Product Owner focuses on maximizing the value and ScrumMaster on improving teams and organizations.

I also like the new Scrum Guide to make the scaling approach clearer than before: “If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.”

#4 – Product Goal, Sprint Goal, and Increment

Finally, the last change is the new language about Product Goal (new) and Sprint Goal (improved), and Increment (clarified). All over the Scrum Guide is catching up with the industry and adding a Product Goal as an artifact. It also provides a definition of a product, which is much broader than many organizations think: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.” Product Goal is a long-term objective for the scrum team – a vision. Sprint Goal gives meaning to each sprint and defines the value we are focusing on now. The increment is a useful output. Well done, verified, and delivering value towards the Sprint Goal. Simple and straightforward. Finally, there is a much better language about the Definition of Done: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” It’s almost like a poem.

All over, I really like the new version. It doesn’t change much from what I was teaching and using, just brings a more clear and crisp definition of Scrum as I know it.

Great Product Owners

Great Product Owners are not only having business knowledge, authority and time, but also a few additional skills which people often don’t expect.

“Great Product Owner is a facilitator, coach, negotiator.”

You will usually hear about coaching and facilitation in the connection with the ScrumMaster role. So why do we talk about Product Owners and facilitation and coaching? Can’t they just use the service of the ScrumMaster? They can. However, in many environments Product Owners are not the ‘heroes’ who decide on everything. Quite the opposite. They are great listeners, who have respect for different customer voices, and their highest value to the system is they can find alignment through coaching and facilitation. Customers (users, stakeholders, shareholders, sponsors, …) never agree with each other, they all have their own preferences and needs. Great Product Owners can help customers to reconnect with their needs instead of pushing what they want. In order to be able to do so, they need to step back, acknowledge that their requests are representing just one way of achieving their goals, and search for other options that would satisfy the needs of more groups than before. In other words, they need to be good at integrative negotiation and finding win-win solutions.

Finally, the last skill great Product Owner needs is visual facilitation. It seems like an unimportant skill, but the good picture speaks for more than a thousand words and can create real magic in searching for alignment. Visualization creates transparency, and transparency is ground for accountability. You would be surprised how good visualization of a conversation and different perspectives can help people to change their mind and proactively help you in searching for alignment.

Maybe those skills are not on the top of the Product Owners list at the beginning, however, the same skills differentiate great Product Owner from the newbies.

10 Most Common Mistakes of Product Owner

Being a Product Owner is not simple. At the end of the day, Product Owners are responsible for the overall Product success. They need to have business knowledge, authority and time. But let’s have a look what are the typical mistakes of a Product Owner as this is one of the very common questions at the classes and learn from that perspective. Here is the list:

Doesn’t Have a Vision

Without a clear vision, there is no direction, no way Product Owner can prioritize, and no Scrum. It’s just a mess where all we can do is to say “everything needs to be done”. The key responsibility of the Product Owner is to have a vision and be able to share it with everybody. Agile organization is about having an evolutionary purpose. If you don’t have it, why are you even here? Similarly to the vision, we have a Sprint goal in Scrum. Without it, everything seems like a good idea to do in Sprint. Sprint goal helps us focus on the need, the real business value.

Can’t Say No

There is no way you can do everything. There are so many options in a complex world. So much functionality customers can ask for. The Product Owner who says yes to all wishes from the customers will fail as the quantity will burn out the organization. Instead, Product Owners are prioritizing based on the business value, and as 80% of value is hidden in only 20% of the functionality, they need to say no quite often during their prioritization.

Doesn’t Have the Business Knowledge

Business knowledge is wider than just a product understanding. It covers the understanding of customers, the market, and the competitive landscape. Without such deeper understanding, Product Owners can’t make a decision and are drafted by different stakeholder groups into their politic fights and the products are usually failing to deliver the real value. Product Owner doesn’t have to be technical, but the business knowledge is critical to their success.

Can’t Prioritize

Product Owner who believes everything needs to be done is not a Product Owner but customer or stakeholder. Prioritization is key in Scrum, at any time you shall know what is more important than the rest and what are we going to invest our energy (effort and money) into next and the rest later or never, depending on the feedback and impact we achieved by the value delivered. There is always more functionality which can be implemented. But maybe that little we already did is good enough for now and we can focus on some other more important areas. As I said already, 80% of value is hidden in only 20% of the functionality. There is no need to implement 100% of the ideas you have.

Don’t Have Negotiation Skills

The Product Owners without negotiation skills are very weak Product Owners. They often end us accepting everything customers ask for and are struggling to say no. Negotiation skill help Product Owners to understand not only what the users want but also what they need. Ant that’s the key part of the prioritization.

Estimates are the Key

Product owners who focus too much on estimates are mentally tight to the functionality, not the business value. In the traditional world, the estimates are important as all we care about is delivery, and we need to deliver more. In the Agile world, it’s not about delivering features. It’s about achieving certain business value. And those two have often only very little in common.

Doesn’t experiment

Product Owners who believe they can create a plan (in agile called Backlog) and then step by step execute it with the development teams during Sprints are not real Product Owners. Backlog can’t be farther from a plan and an iterative approach of delivery is here to inspect and adapt and learn from experiments. Find out where is the real value. The approaches like Lean Startup are quite useful here.

No Impact

As we said, Product Owner shall be able to run experiments. In a way, every backlog item is an experiment where you expect something will happen as a result. That’s the impact. Without knowing why you invest team time and energy into it, why to do it in the first place? Running an experiment without knowing how are you going to evaluate it is silly. That’s not an experiment but functionality you plan to deliver no matter what. Why? Because it’s important. Because I said so. Instead, spend more time identifying the impact so you know why you do it and what you expect to happen. Tools like Impact Mapping are quite helpful here.

Multiple Products

Or shall I say systems, or projects? Because product definition is much wider than that. Product Owners taking care of multiple product don’t have focus, and often don’t have time. Considering Product Owner is the person responsible for the overall product success including the return of investment, it’s quite useful to have the focus for making the product successful and don’t switch the context all the time.

Not Part of the Team

Product Owners sometimes feel they don’t belong to the team. They act as Backlog managers, telling the team what to do, and then waiting to get results/blaming at the end of Sprint. Instead of that, Product Owners are part of the Scrum team, they are team members, they shall collaborate with the team on delivering the value and achieving the Sprint Goal. They are part of the team.

Do we need CEO in Agile Organization?

Agile at the organizational level changes everything. I wrote here already about Agile HR, Agile Board of Directors, and Agile at the Executive Team Level. Let’s have a look at the top of the organization. Should it remain the same? Or shall we go one step further and change it as well?

Searching for an “agile mindset CEO” is frankly a nightmare. Everyone who tried it can confirm that. There are not many CEOs with enough Agile experience yet in the world and those few who has it are not likely looking for a job as they are usually quite happy in their current organization. So, no matter which executive search firm you choose, or what you write to the position description, the search firms are no real help here. Unless you already spent effort up front on growing the talent internally, you need huge luck to get someone who understands agile more than a basic theory. No matter how desperate you are searching for a CEO, this is still just a small obstacle, not the real reason for a structural change.

The real need for top-level change starts when most of the organization is having an agile mindset. The Agile transformation is about being agile. How many times you’ve heard this request: “How about if our management give us more support on your Agile journey?”, “How about if our executive team is Agile and don’t just push it to us?”, “How about if they practice the same way we work as well?”Would that make it a difference? Maybe. So why don’t we go one more step ahead and change from the top and become a role model for the entire organization? As the organization has changed and Agile is not solely the domain of the IT anymore, but the business agility got into every department, the need for a change at the top level is inevitable. Why do we need a CEO in the first place? Just because that’s how organizations always been? Shouldn’t we ‘eat our own lunch’ and change the way we work entirely? Shouldn’t we apply the same principles the team do? Sounds simple, right.

And as usually it is simple to understand, hard to do as it needs courage. Courage to say “We are going to be different.” We will have Organizational ScrumMaster and Organizational Product Owner instead of a CEO because it will be closer to the way we work at this organization, fits our values, and last but not least we believe it will help us to be more flexible and adaptive at the organizational level. And that’s worth of trying.

The Organizational ScrumMaster would be focusing on the right culture, mindset and structure, so we become high-performing innovative organizations which embraced agility, and Organizational Product Owner would be focusing externally to the business, vision a purpose to we know where are we heading and why and are value driven. Both roles need to respect each other and be open with each other, the same way as it is in a single Scrum team, as together they will be part of the Organizational Leadership Team, and the network structure of self-organizational teams. There are two roles in Scrum by a reason instead of one. When you ask people if they would suggest to combine them, no one feels it is a good idea. And at the top organizational level, we would still do it? The similar reasons are valid at this level as well. When you think about it, it fits the way we work much better, then a single CEO – supports the right organizational mindset, transparency, and collaboration, it is consistent with who we are.

From a legal perspective, it is perfectly possible, and it’s not that much work either. You might need to change the bylaws a little, but there is no reason why you can’t do it. From a hiring perspective, it’s much simpler, as you are not looking for that ‘superhero’ personality who would be great with both internal and external sides. Try it. As I said already, all you need is courage. And that’s one of the Scrum values anyway. Experiment, and from that stage inspect and adapt. Now, do I believe that this SM-CEO or PO-CEO will eventually make themselves out of job? No, I don’t. It’s the same as the team level. Even if the team is self-organized and knows the business well, there is still work for ScrumMaster and Product Owner. Similarly, at the organizational level, there is still a need for Organizational ScrumMaster and Organizational Product Owner even when the network of collaborative teams got self-organized, business value-driven, and customer-centric. The Organizational ScrumMaster and Organizational Product Owner would use Leader – Leader style to build other leaders around them, and if they are successful, the organization will become purpose driven where leadership will be emergent and structure liquid. The same way as it is in the Scrum team, the Organizational ScrumMaster and Organizational Product Owner will move from those who explain, tell and share, to those who coach, facilitate, and keep the system spinning. And that’s what is the Agile Leadership about.

Five books every Product Owner should read

To continue my with my book recommendations (check the five books every ScrumMaster should read, and five books Agile Leader shall read), I have several books here, I would recommend every Product Owner to read. It’s a mix which will help you to understand Agile Product Ownership, Discovery and delivery process in much broader perspective. Enjoy reading 🙂

Impact Mapping: Making a big impact with software products and projects is a practical guide to impact mapping, a simple yet incredibly effective method for collaborative strategic planning that helps organizations make an impact with software. Impact mapping helps to create better plans and roadmaps that ensure alignment of business and delivery, and are easily adaptable to change. Impact mapping fits nicely into several current trends in software product management and release planning, including goal-oriented requirements engineering, frequent iterative delivery, agile and lean software methods, lean startup product development cycles, and design thinking.
Agile Estimating and Planning is the definitive, practical guide to estimating and planning agile projects. In the book, Agile Alliance co-founder Mike Cohn discusses the philosophy of the agile estimate and planning, and shows you exactly how to get the job done with real-world examples and case studies. This book is a must-have agile estimation tool for your development toolbox.
User Story Mapping: Discover the Whole Story, Build the Right Product shows you how changeable story maps enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why. This insightful book examines how this often misunderstood technique can help your team stay focused on users and their needs without getting lost in the enthusiasm for individual product features.
Innovation Games®: Creating Breakthrough Products Through Collaborative Play is a must-read for anyone involved in market research and product or service development (which, when you think about it, means virtually everyone). Innovation is incredibly simple. All you have to do is accurately predict what your customers want, need, and will pay for. Oh, wait. Sorry. That’s actually very hard. At least with traditional tools. So how do you find this information? Well, you can just ask your customers what they want. The problem, of course, is that with most truly breakthrough innovations, current and potential customers don’t actually know what they want before they see it. If you just try to deliver what they already want, you’ll never truly innovate. Even worse, traditional market research practices prove that often, customers have trouble articulating what, exactly, they want in the first place.
The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses is about a new approach being adopted across the globe, changing the way companies are built and new products are launched. The Lean Startup approach fosters companies that are both more capital efficient and that leverage human creativity more effectively. Inspired by lessons from lean manufacturing, it relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute. Rather than wasting time creating elaborate business plans, The Lean Startup offers entrepreneurs – in companies of all sizes – a way to test their vision continuously, to adapt and adjust before it’s too late.