Introduction to the Collaborator

Obviously, Scrum is all about collaboration in the Scrum Team between the Product Owner, Scrum Master, and Developers as well as between the Scrum Team and stakeholders, users, and customers. The Scrum framework provides the events, artifacts, and Product Owner accountabilities to optimize collaboration in order to deliver done, usable, and valuable work at each Sprint. The ability to collaborate with other people effectively is a core skill for any Product Owner.

So far, we’ve discussed various tools, techniques, practices, concepts, and tips around effective product management. Although it wasn’t explicitly mentioned earlier, most of the contents from previous parts require plenty of collaboration. You can collaborate on the vision, strategy, goals, personas, market analysis, experiments, and so forth. What is so special about the Collaborator stance?

For starters, here are some positive outcomes and benefits that we have observed when Product Owners take the Collaborator stance:

• Improved flexibility of the organization: When collaboration improves, so does the organization’s ability to handle change. Strong teamwork and collaboration make it easier to pivot when the customer needs change or when disruptive technologies or competitors enter the marketplace.

• More engaged employees: “Unfortunately, only 33% of employees in the US are engaged,” says Nick Sanchez, chief people officer at Namely.¹ This is a big risk for many organizations; however, it seems that one of the best ways to get workers more engaged is to improve teamwork.

  1. Kat Boogard, “Employee Engagement Strategies That Work,” Wrike Inc., October 15, 2021, https://www.wrike.com/blog/5-strategies-employee-engagement/#Why-employee-engagement-matters.

• More productive meetings: Meeting efficiency and effectiveness increase when people and teams are collaborating effectively. With proactive teamwork enriching the corporate culture, workers need fewer meetings as they accomplish their tasks and use tools to document work progress or delegate work yet to be done. And when meetings must be held, there is more proactive information sharing, more engagement, and more support for each other’s efforts.

• Accelerated business velocity: With a collaborative culture, you gain the ability to bring products to the market faster. Teamwork and communication speed up the entire process and make it easier to produce anything. The entire organization’s ability to create value accelerates as a result.

• Innovative ideas: Sure, collaboration is never easy. It generates as much friction as it does productive output. But surely there is a silver lining behind all that friction between conflicting personalities and work styles, right? Right! It generates dynamic, innovative ideas. And without those new and vibrant ideas, your organization dies a mediocre death.

• Better alignment with stakeholders: When you talk about collaboration, it’s a good idea to especially focus on external collaboration with your customers, partners, and vendors—the stakeholders whom your product directly affects. If you can leverage their feedback into your product development process, then there will be better alignment between the customers’ actual needs and your product’s features. Win-win.

• Increased profitability: And then, of course, there’s the bottom line. Collaboration improves it because after recruiting all the superstar geniuses and building a culture worthy of their skills, they get to work generating the innovative ideas that will propel you forward and bring home the bacon. Everyone is happy!

Although there may be many other benefits, regularly taking a Collaborator stance as a Product Owner should lead to improved team performance, more effective collaboration, happier and more engaged Developers, and increased customer and stakeholder satisfaction.

So, collaboration is important and valuable. Collaborating with other people is also something that many Product Owners in practice do automatically. It’s part of the job, and it’s necessary. There are, however, elements such as governance and compliance that may greatly impact the ability to collaborate. In addition, we sometimes need to work with external parties for which contracts are created. Or we might be contracted by another party ourselves. And of course, product finances and budgeting influence collaboration as well.

Here is what great Collaborators do:

• Great collaborators are open and transparent: Telling stakeholders and teams the truth is part of being open and transparent, of course, but it tends to happen after someone has asked a question. Being open and transparent goes beyond answering questions honestly to proactively and openly sharing information that may or may not be relevant to the stakeholders and Developers. Transparency builds trust because people will never feel as though the Product Owner is keeping something from them.

• They say what they do, and they do what they say: Nobody likes to work with people who drop the ball, even if it just happens on occasion. Beware: dropping the ball isn’t the same as making a mistake. In complex environments, people make mistakes, and that’s part of the complex work that we typically do. Strong Collaborators, though, can judge how long it will take them to get something done and then manage their schedule to deliver on time. People can count on them to do what they say they will do, and consequently, people love working with these great Collaborators.

• They allow for a little give and take: Collaboration should benefit everyone—not just Product Owners but the teams, the individuals on the teams, and the stakeholders. A question great Collaborators ask themselves is, What am I contributing to this relationship and how am I supporting the greater good? Stakeholders and teams are more likely to help Product Owners who are willing to collaborate with them when they need help as well.

• They listen to understand, not to respond: Great Collaborators know that people like to be heard and to know that their ideas and thoughts are being taken into consideration. Listening to each other and exchanging ideas and opinions is a key element of collaboration. Product Owners who want to be effective Collaborators must listen—truly listen—to all parties and be prepared to make changes based on their input and feedback when it makes sense to do so.

• They are open to other options, and they are willing to compromise: Collaborators understand that life isn’t about always being right or winning every battle. Good Collaborators choose their battles. They know that just because they prefer option A over option B, it doesn’t mean that they should always fight for option A.

• Collaborators are kind to those they collaborate with: Product Owners carry a lot of weight on their shoulders. Between the endless work to be done and the many deadlines to deliver on, the pressure can wreak havoc on moods and manners. However, great Collaborators know that work can get done without making enemies along the way. People work harder, smarter, and faster when they like the people they work with. To maximize the value of their product, Collaborator Product Owners are kind to those they want—and need—to collaborate with.

• They understand that they need to step up: Great Collaborators understand that collaboration is a two-way interaction. When collaborating with others, they don’t settle for doing the bare minimum, and occasionally go above and beyond in unexpected ways. They gain a lot of goodwill and buy-in because people know they will step up to the plate when necessary, which makes collaborating with them a lot easier.

In this part, we focus on increasing your knowledge and understanding about various elements that influence your collaborative abilities, such as governance, contracting, and finances and budgeting. The first topic? Let’s talk about governance.

Introducing Agile Governance

Every organization, small, medium, large, or enterprise, needs a form of governance. What is governance? What does governance relate to? There are many different definitions, types, and elements of governance. There is corporate governance, for example, as well as project governance, portfolio management governance, financial governance, and so on. You may find that the definition of governance varies greatly among organizations.

Although most Product Owners don’t get too excited about governance, it will help you in your work to have at least some understanding about it. In addition, because there are so many different perspectives on governance, it will likely prove to be helpful to reach a consensus in your organization about what governance means. It may help you to reflect and argue some of the rules, policies, and agreements made in the company.

Organizational Governance Entails Many Elements

Governance is a broad topic. It can be connected to many different elements. The rules, processes, and agreements made in your organization about topics such as risk management, documentation, technology, architecture, security, privacy, and so forth, are all part of the organization’s governance. Most of this governance is defined internally and can therefore be changed. Some of it might be external governance and more difficult to change.

Figure 25.1 shows various elements that are likely part of your organizational governance. Although not all elements might be applicable, most probably are if you are working in a small or mid-sized company or large corporation. This list of governance elements is far from complete, but listing everything that has to do with governance would result in dozens of pages, and you’re not likely to read that as a Product Owner.

During our Professional Scrum Product Owner-Advanced courses, we often run this governance chapter as a series of exercises. One of the exercises includes organizing all these governance elements into groups: internal vs. external governance, and as a second step, connecting them to the Product Owner versus Scrum Master versus Developers versus outside the Scrum Team, as shown in Figure 25.2.

During this exercise, people start discussing what the governance elements mean. For example, risk management, finance and budgeting, and change management are often linked to multiple roles, typically including the Product Owner. The takeaway is that the point of this exercise is to discuss what these elements mean. Let’s explore two examples.

Risk management can be connected to the Product Owner. It’s the Product Owner’s responsibility to identify strengths, weaknesses, threats, and opportunities for the product as well as to order the Product Backlog and to consider value and risk in that ordering. The Product Owner also assesses risks in the market, product, and industry to handle in the product. Risk management can also be related to risks in technology or in the solution space. Identifying and assessing potential security, stability, and performance risks can be taken care of by the Developers. Then there are risks related to the process, culture, people, and way of working. Risks that might prevent the Scrum Team from achieving the Sprint Goal (impediments) or risks that jeopardize the application of professional Scrum can be taken care of by the Scrum Master. And of course, there is the perspective of risk management in large corporations, like banks. These companies typically have a risk management function or department. These groups of people do risk management all day long. It’s their job to identify, assess, communicate, and manage corporate-level risks, such as those that may affect the bank’s license to operate.

Let’s inspect a second example: product documentation. How you handle product documentation may be completely up to your team and the company. Some (typically smaller startup-like) companies don’t have any governance about documentation at all. Other organizations set standards for documentation such as technical, user, architectural, in-code, marketing, sales, operational, and more. With product documentation—that is, documentation about the product’s unique value proposition, customer problems to solve, and key features—the Product Owner likely plays a role. With technical or architectural documentation, the Developers likely take responsibility. Documentation about the way of working, culture, and values is likely worked on by a Scrum Master. And there may be many other forms of documentation used outside the Scrum Team. In some cases, you need to comply with industry standards. For example, pharmaceutical companies need to always include prescribed use with their medicines. Other companies need to be able to track changes in documents, processes, or systems.

You’ll notice in these examples that governance elements can be explained in many ways. There is (at least some) room to define your governance and your ideas. And that’s the thing about governance: for the most part, it is whatever you and your company define it to be and describes who is accountable and authorized to make decisions and how it needs to be handled. So, if governance is mostly defined by us, then we can also change it!

Effectively Dealing with Governance

To change existing governance or install new governance, you first need to define what governance or its elements mean in your context. You may have discovered that most of the processes, rules, and regulations are internal governance, but some might be outside your circle of control or influence. This is usually the case with legislation of industry standards.

Over the past 20 years, we’ve heard many people say things like, “That’s just how it works here” or “We’ve always done it that way.” Although that might be true, and although things have indeed been done in a certain way for potentially a very long time, it doesn’t always mean that it must stay that way. Most of the governance defined in organizations is still internal governance. So, if you run into issues that block you from being an effective Collaborator, try to change it. Of course, not every battle is worth fighting. But, if you truly believe that you could be more effective at maximizing value if the governance were changed, then you probably should make the effort.

With most governance elements being internally defined, a Collaborator Product Owner could enlist the help of the Scrum Master and Developers to change the governance. Although it is often not the case when you have just started your Scrum adoption, trusting a Product Owner to handle the product vision, strategy, roadmap, decision making, and product finances should make sense. Taking ownership of return on investment and longer-term product success leads to faster decision making and more ownership, so a Product Owner should likely step in. Similarly, process improvements and process management are great elements to be tackled by a Scrum Master. Personal coaching is a profession. Perhaps not all Scrum Masters make outstanding personal coaches, but the great ones do. Define what this governance element means, and then see who should take ownership of it. Many things can be handled by the Developers, especially when they have grown beyond code writers and have become product Developers with the skills to develop all aspects of the product. Self-management of the team happens within boundaries; governance can make these boundaries transparent and allow the teams to grow.

Some things might also be outside of your control. You might contribute to elements such as organizational culture and internal auditing, for example, without actually owning them. Perhaps you don’t even need to influence or know about some of the example elements listed in this chapter, but having some awareness of them is useful. Although there is a lot of work to be done by a Product Owner already, there are two governance elements that don’t get enough attention in most organizations: budgeting and contracting. These elements are important for a Product Owner to consider, so we offer you some additional guidance and inspiration on these topics in the next chapters.