What a Scrum team can benefit from some of the PMBoK tools and techniques.
This is a hot topic. Most of the agilists I know of, disregard the PMI and the PMBoK altogether, considering it the mother of all evil. But if you take an unbiased look at the tools and techniques preached at the PMBoK (or the Prince2 Guide, or the IPMA Handbook), you will find some tools that are universally useful. And most of the useful ones can help a lot the POs (and sometimes the SMs).
Why the POs? Well, I believe the PO role is the most challenging one in a Scrum setting. You have to have such a broad set of skills, knowledge, aptitude, mindset and passion, that most of the time you are unable to find them all in the people you are trying to recruit.
You may find a few structured literature to help the PO out. You have some tools and books for story mapping, a lot of resources for the concept of MVP (at the Lean Startup) to help in the prioritisation, you have the OKR framework for goal-setting and alignment, you have some tools for organising and managing the roadmap and you have the queue theory and the theory of constraints to help you out in managing your backlog queue. But that's most of the resources you will find. For the rest of the role's job, you have to google a lot.
But, if you look at other frameworks (both for Product and Project Management) you really can make use of a lot of other resources.
Since the PO has a lot of interface with people outside the team, the PO needs to understand the environment in which she is working on. The organisational structure may be a good starting point.
- Is there a Product Director? Or the product group lies under the marketing organisation? Or does it lie under the engineering group?Is it a functional organisation? Is it a product-base organisation? Is it a matrix organisation?
- Are there any product committees? Who are the people attending at such committees? Which people are most influential?
- Is the company a "product company" or a "service-provider company"? How strong is the product culture and mindset?
- How does the rewarding and punishment systems work? Does it favour the hero, or it favours a culture of teamwork?
- How centralised / decentralised is the decision-making process?
All these questions and its answers may help the PO in her quest of building a great product.
More about "Organisational Culture, Structure and Influence" can be found at the PMBoK 5th Edition, on chapter 2, section 2.1.
Managing the stakeholders of a product may be a very challenging task (depending on the product and on your organisation). Sometimes the first challenge simply lies in identifying properly all stakeholders (both the formal ones and the informal ones).
It might be useful to perform some kind of stakeholder analysis, assessing the level of influence/interest and power for the main stakeholders and also understanding the level of engagement of each, so you can properly manage them.
The PMBoK is expanding and enhancing this subject area. It was a single paragraph, and now it's a whole chapter. Despite the bad and difficult format, it may be worth reading. You can check it on the chapter 13 of the PMBoK 5th Edition.
Understanding the communication process is important. In the default agile team setting, most of the communication is done face-to-face at the ceremonies. But if you have the PO on a different location of the stakeholders, this face-to-face conversations probably can't happen! Properly managing the communication process might help in these cases. In this regard, understanding the communications requirements (who needs what information, when it is needed, in which media, etc), and using the proper communication channels and technologies (formal emails, conference calls, video calls, wiki's, etc) might be critical to the project success. You can also use this techniques to talk to your audience (the audience of your product).
Communications management is even more important in the case your stakeholders don't play the same "agile game" played by team. So, it's pretty useful to check the chapter 10 of the PMBoK for more details in this subject area.
A lot has been said about how agile methods mitigate risks. But sometimes, we are not talking only about technical (or product) risks. Sometimes it's a new environmental law that may endanger your product, or a unanticipated lay off that could ripe apart your team. The point is that not all risks can be managed adding (or removing) a user story to (from) your backlog. Sometimes, that are a lot of issues not directly under control of the team, so monitoring and having some response plans in place might be a good thing to do.
Properly managing risks is critical in today's ever changing environment, and using the processes of the PMBoK can be of great help. You can check the PMBoK chapter 11.
This topic is almost untouched under most of the agile methods.
If your product uses free/open software and the only costs are the people cost and the infrastructure costs, it's fairly easy to manage the product cost/investment.
But in case you are integrating a lot of components from different vendors, using outside contractors/vendors to build some part of the product, using any kind of consultant, etc, this task could complicate a lot. And there are also the product financials: ROI, trade-off analysis, and a lot of stuff in the product management that navigates through the cost/investment arena.
Regarding cost management you can check the PMBoK chapter 7.
Human Resources Management
What about the people side of the team? In Scrum the team is responsible for its members. How? They have to figure out for themselves. Well, there are tools for identifying staffing and coaching needs, development plans and so on. Actually there are a lot of literature on developing people skills and creating high performance teams. But this is not properly covered in a Scrum setting.
For more information, check the chapter 9 of the PMBoK, and more specifically the section 9.3 (Developing the Project Team).
Program and Portfolio Management
Most of the literature covers teams and "stand-alone" products, teams building non-related products, or products with little integration among themselves.
But when you have one (or more) complex product lines, integrating different sub-products, it is necessary to coordinate the separate products backlogs and roadmaps, and still manage your portfolio.
In this area, the PMI has written 2 complete guides, one for portfolio and one for program management (Standard Program/Portfolio Management Guides).
Does your team need to buy goods or services? Well, this is not covered at the Scrum Guide. In this subject area you have to be careful, since you may ending up using a command-and-control type of contract. But, the PO can have a good help from tools in the chapter 12 of the PMBoK (Project Procurement Management).
In the case of your vendor also uses agile, it may be a lot easier to reach an agreement regarding contracts and terms. But if not, understanding the world of RFIs/RFPs, make-or-buy decision analysis and some other common negotiation tools may help a lot the PO in her procurement efforts.
So, what's my point?
Although the PMI mindset is much the opposite of the agile mindset, you still can benefit a lot from some tools and techniques assembled in those guides.
Sometimes, the PO have to interface a lot with other organisations and people with different backgrounds and not using agile yet. In this case, it's important for her to be able to navigate in such environment as well.
So it's dead simple. Keep your mind open to learn from whatever sources may benefit you. You and your team can make good usage of this!