The Role of an Agile PMO
[Note: This was first published by Cutter Consortium in an Executive Update. I am a senior consultant for Cutter Consortium]
by Lynn Winterboer, Senior Consultant, Cutter Consortium
Organizations seeking to respond quickly in an ever-changing marketplace are asking more and more from their data warehousing (DW) and business intelligence (BI) teams. Fortunately, many BI teams are finding they can meet top-priority needs in short time frames when they adopt Agile practices. Within an Agile team, the product owner (PO) guides the team’s priorities to meet the organization’s goals.
Product owners for Agile BI teams often face unique challenges compared to their peers on other functionally specific delivery teams. An Agile project management office (PMO),1 as we explore in this Executive Update, helps mitigate some of the key additional challenges BI teams face, thereby allowing the BI product owner to more effectively drive high-quality, high-priority results for the organization.
The role of product owner on an Agile team carries substantial responsibilities. The PO must do the following:
- Identify the business needs.
- Write and refine good user stories that accurately reflect the drivers and details of each need.
- Prioritize the user stories into a backlog.
But these substantial responsibilities are only a portion of what a BI product owner must do. The PO for a single BI team that supports multiple business functions, such as sales, finance, service, and HR, has a bigger challenge. His or her challenges, beyond what other product owners face, include:
- Understanding the drivers and values of each business function in order to groom strong user stories.
- Prioritizing stories across these multiple business functions to come up with a ranked backlog that represents the organization’s overall priorities.
- Aligning the unique business intelligence value chain with Agile practices
Although a BI team can certainly find ways to mitigate these challenges without a PMO, it’s awfully nice to work in an organization that has a strong Agile PMO, which can help the BI product owner tremendously by:
- Facilitating cross-functional communication and understanding
- Driving and enforcing corporate priorities across teams
- Providing coaching to newly Agile teams
FACILITATING CROSS-FUNCTIONAL COMMUNICATION AND UNDERSTANDING
An Agile PMO facilitates cross-functional collaboration for the business as a whole. A key component for Agile enterprises is the Scrum of Scrums, which is a regular gathering of representatives from all the Agile delivery teams where they communicate what they have accomplished, what they are working on next, and where they need help from another team or otherwise have roadblocks to success. An organization can certainly hold a Scrum of Scrums without a PMO to coordinate and facilitate it, but the best PMOs I’ve seen do a great job of this, as well as helping to remove roadblocks that arise.
The information that comes out of the Scrum of Scrums is incredibly useful to the DW/BI team that needs to understand multiple business domains and their source systems (that the other teams support). For example, since our product is often dependent on data from these other teams’ systems, we need to know if those systems are changing so we can react appropriately. We also benefit from being involved early on in source system enhancements so we can extend the value chain of the new functionality by eliciting user stories for the key reporting and analytics the business will need in order to fully leverage the new functionality.
BI teams benefit from having this help because it allows them to focus on BI-specific activities while the PMO focuses on cross-functional facilitation and communication tasks. It is much easier to participate in a cross-functional meeting than to define, schedule, facilitate, and participate in one! Without the Scrum of Scrums, a BI product owner would have to find ways to gather this information elsewhere.
BI product owners are also often required to be (or become) subject matter experts on several business domains at the same time. Ideally, the product owner would have deep experience working in each business domain that he or she represents. A product owner for a sales application, for instance, would benefit from having worked as a salesperson in the field. Similarly, a finance analyst would make a fine PO for a finance application. However, there aren’t many people out there who have worked as both a salesperson and a finance analyst, which would be ideal for a BI product owner who supports both sales and finance BI needs.
Therefore, the PMO, which also must satisfy the needs of multiple stakeholders, has insights into the priorities and challenges of all business domains and can be helpful to a BI product owner who is stronger in some and less knowledgeable in others. I have found the PMO to be particularly good at pointing out synergies and conflicts between business domains, so the BI product owner doesn’t have to discover these issues on his or her own.
DRIVING AND ENFORCING CORPORATE PRIORITIES ACROSS TEAMS
Corporate-wide priorities are critical to BI teams because we need to understand which of our multiple stakeholder groups’ requests are the most important to the organization’s overall goals and therefore work on those first. Many of us in the data world have often experienced situations where the reporting and analytics considerations of large projects are not thoroughly considered until after the source system and business process reengineering are well under way. This mistake can be avoided. For instance, one of my clients holds a monthly steering committee, facilitated by a very effective PMO, which brings the product owner and technical lead of each delivery team together with the company executives to review and prioritize key features and risks. This approach ensures the BI team is working in line with corporate priorities, and puts the BI-related efforts to support key system initiatives on par with those initiatives.
A good Agile PMO will also ensure delivery teams actively support corporate priorities. The PMO therefore provides a natural “backup” to the BI product owner when one department’s project is a higher priority for the BI team than another’s. For a BI product owner who serves multiple stakeholder groups, it can be hard to have to “push back” on several of them while the BI team focuses on the top priority. Having a strong Agile PMO partner can be really helpful in taking the emotion out of the situation by reminding stakeholders of the priorities the company’s executives have set and maintained in the regular steering committee decisions.
PROVIDING COACHING TO NEWLY AGILE TEAMS
The strongest Agile PMOs I’ve seen are very good at helping teams that are new to Agile “hold the Agile process” and not succumb to the temptation to start making exceptions. A BI team that has multiple stakeholder groups, specialized tools (and related skill sets), and large volumes of data certainly has some additional challenges than other IT teams.
In addition, while many IT teams support a single system, BI teams often support a process with layers of systems: from source to staging to integration to data warehouse to cubes to BI and analytic applications. This unique aspect of the BI value chain has, over the years, been a driver for BI teams behaving differently than their IT peers.
It is therefore tempting to say, “We’re different, and therefore we can’t adhere to ____ Agile value.” A good Agile coach can help the team think through its approach and find ways to adhere to the core values and principles of an Agile approach.
For example, exceptions I regularly see when coaching teams include:
- Separating DW and BI user stories, which leads to an exception to the Agile tenet, “Satisfy the customer through early and continuous delivery of valuable software.”2 I don’t know many business stakeholders who are satisfied with a key metric being available in a table in the data warehouse. They often want it in a report or on a dashboard before they find value in it.
- Developing in a “mini waterfall” within each iteration, leaving testing of all stories to the end. This practice shortchanges the testing activities (just as it does in a traditional waterfall process), and goes against the grain of continuous attention to technical excellence.3 It’s very difficult to deliver technically excellent code when it hasn’t been well tested.
- Avoiding test automation because the most popular tools out there are GUI-focused and don’t necessarily test “data.” Any Agile team can quickly get overwhelmed with the amount of regression testing required with iterative development; test automation is incredibly helpful here. BI teams, which are used to specialized tools for almost every aspect of what we develop, are often hesitant to take extra time and effort to figure out how to automate their tests.
An Agile coach is in a position to challenge these practices and talk the team through an assessment of the pros and cons of each to determine whether they will contribute to the organization’s Agile goals overall, or end up causing more problems than they are worth for the near-term convenience.
With a strong Agile PMO, the BI product owner can now focus on BI-specific activities while the PMO facilitates cross-functional prioritization and communication, enforces company priorities, and provides Agile coaching when needed.
1Well-known Agile author and trainer Mike Cohn writes more comprehensively on the role of the PMO in an Agile organization at: Cohn, Mike. “The Roles of the Project Management Office in Scrum.” Mountaingoat Software, 1 September 2010
3“Principles Behind the Agile Manifesto” (see 2).