Successful Agile in government: Supporting the product owner

While a growing number of government organizations are looking to take advantage of the benefits of Agile development, not all of them may be fully prepared for the level of commitment needed from their own people and stakeholders to enable success. This paper looks at some common pitfalls of under-resourcing and under-supporting one of the most crucial roles in Agile, the product owner.

The product owner: The linchpin of Agile

The product owner (PO) is a role unique to Agile, and a capable, well-supported PO is critical to the success of Agile development implementations.¹ The PO has three key functions in the Agile process:

1. The PO is responsible for representing the business’s and end users’ interests to the development team, including managing the backlog and prioritizing the work of sprint teams. The focus here is on usability and adoptability.
2. The PO plays a key role in the milestone demos that an Agile team will be providing throughout the process—acting as both the recipient of the demos from the development team as well as conduit, participating in demos to senior management. The PO in this role may either copresent the features as they develop or act as tour guide for senior management, answering key questions to help fully illuminate how the project is coming along.
3. The PO is also responsible for ensuring that decisions on choices that arise during the development process get communicated to the development team in a timely manner. This doesn’t mean that the PO has to make every call on his or her own—few POs will or even should have that sort of authority—but they do need to be able to command the attention of senior management to streamline the decision-making process rather than allow lingering questions to fester.

For those new to Agile, the PO role is often confused with the more traditional project manager role—but they are different. While the project manager focuses on resource management, keeping the project on track in terms of time and expense, the PO maintains a laser focus on ensuring that the software delivers the business benefits envisioned by the agency. More than anyone else on the public sector side of the equation, the PO should understand the ins and outs of how the software will actually work and provide value to end users.

Why can the product owner role be especially difficult in government?

The PO role is challenging in almost any Agile development effort, whether public or private. A good PO has to bridge the gaps between business users, developers, the IT department(s), senior management, and even external stakeholders such as advocacy groups and third-party providers. A PO has to be part business analyst, part technologist, and full-time diplomat—a communicator who commands respect throughout the organization, while often operating without a large staff, extensive authority, or a lofty title.

While the PO role is a linchpin role in most Agile projects, it may be even more challenging in the public sector, for a couple of key reasons. The first is that skilled managers of the sort described above are scarce resources in government—or in any organization—and an employee who fits that description is almost always engaged in a critical role already. It is very hard for senior management to reallocate such a talent—but it is crucial for the success of an Agile project.

The second is that the PO will have to battle an environment more rule bound than the private sector. While politics and bureaucracy do exist in the private sector, they are rarely as intense as their public sector counterparts. Unlike private entities, our democratic institutions require a level of transparency and fair process, as well as protocols to limit the likelihood of corruption. This red tape, some of it legislatively required, can hinder execution. In addition, the public sector often presents a high number of stakeholders that have to be consulted throughout the process. In a private organization, many of these obstacles either do not exist or can be eliminated by a single stakeholder such as the company’s CEO.

Perhaps the most common Agile mistake is to name someone as PO without relieving him or her of other duties. The truth is that a PO needs full-time (or very near full-time) focus to successfully manage an Agile implementation; it’s very difficult to effectively handle PO responsibilities while holding down a “day job.” Yet too often we see decision makers short-changing the time commitment required of a PO, with predictably bad results. Sometimes POs are overwhelmed or frustrated, doing neither of their jobs particularly well. Sometimes the PO simply moves on to a different role, leaving the project in limbo. And sometimes the PO is able to successfully juggle the demands of two roles—but, as months pass, eventually succumbs to “product owner fatigue.”

PO fatigue can afflict anyone in that linchpin role, but it is particularly acute when management has insufficiently cleared the plate of the employee being asked to take on the challenge. Too often, we hear of cases where management takes the view of “Everybody is stressed, everybody has a lot of meetings—deal with it.” Then, as the country song says, you’ll only miss them when they’re gone.

Another mistake can be to fail to support the PO, most often by failing to establish mechanisms that allow critical decisions to be made quickly. In this scenario, the PO and developers identify “either/or” decision points: The product will either be made to work on mobile devices, or it won’t. It will allow employees to change records with an audit trail, or it will require manager sign-off. It will allow field workers to override assignments, or it won’t. These decisions are often “above the pay grade” of the PO. The challenge for the PO can then become, who needs to be involved in this decision, and how can I get them to make an informed decision in a timely manner?

It is at this point that the PO can most often suffer a metaphorical nervous breakdown, because the vast majority of these decisions mean trade-offs, and these trade-offs create winners and losers. In government, the complex web of checks and balances means that different stakeholders will likely have different perspectives—but there is often no clear mechanism by which these different views may be reconciled. It often isn’t even clear initially who needs to be involved in making the call. Thus a PO may scurry about on an endless loop, chasing down senior officials from all over government—from secretariat-level officials in the business unit to county administrators to IT architects—but no decision gets made. Or, even worse, decisions get made and then unmade. Further, all of this takes a lot of time, and the “Agile” project may slow down or stall altogether, depending on the nature of the decision.

Supporting the product owner: Strategies for senior sponsors

One approach to mitigate this challenge is to establish a senior steering committee, comprising several senior representatives empowered to meet and deliver a decision. The PO can raise these “either/or” decision points, present the pros and cons of various options, and help the senior steering committee engage in dialogue to reach a decision. There still remains the challenge of timeliness—the group isn’t much good if it takes a month to get them all together—but having such a committee can be a huge benefit to both the PO and the project.

The senior steering committee can also act as a sounding board for project demos throughout the milestones of an Agile project. In Agile, actual demonstrations of working software are typically the key measure of progress toward success—as opposed to Gantt charts, Excel spreadsheets, or multicolored graphs showing a work stream as red, amber, or green. However, to be meaningful, these demos need to be seen by the right people. While the PO would review these demos, it is important that a broad cross-section of senior management likewise has a window into the project. This not only reduces the likelihood of unpleasant surprises down the road, it also allows for creative input along the way. With the PO at the table along with representatives of the development team, these demos can not only provide senior leaders with a better understanding of how the project is progressing but also offer an opportunity to discover previously un-thought-of ways the system could work even better.

In addition to the senior steering committee, many successful Agile projects have one or more key senior “sponsors.” Whether formally named as such or not, these senior leaders make themselves available to POs when the latter hit organizational roadblocks. Sometimes the PO just needs to be able to walk into an office or pick up the phone and make a quick call to someone who knows what is going on, and who can provide guidance without having to wait for the next monthly meeting.

Without sufficient leadership support, the PO may have a difficult time helping to guide an Agile project to a successful conclusion.

The product owner support structure: Context for success

In addition to leadership support, POs need a support structure to help them succeed over the long haul. While some Agile projects can be completed in just a few sprints, more often, a project can stretch out over months or even years. Or, even if an initial project is completed quickly, additional features are added that effectively extend the life of the project.

There are several ways to support a PO throughout the journey.

Tool 1: Create a PO job description

“Don’t worry, of course you’ll be freed up from your regular duties. We aren’t going to name someone to replace you since this is just a temporary assignment, but surely so-and-so can step up for a while.” Assurances of this sort should set off alarm bells for any would-be PO.

A written role description for POs can give them confidence that they are being asked to focus on this new role. This would also help clarify the PO role responsibilities. Often, the PO would keep the same manager, so it is especially important that expectations are negotiated and articulated in advance. In addition, POs are typically go-to people in an organization, and, without a written description, people might continue to go to them with all the old problems, and expect them to keep the shop running as they always have. While a 100 percent focus on the new role might be ideal, an 80–90 percent commitment is usually a good compromise that reflects reality. A word of caution, however: For large implementation projects, the PO should really be engaged 100 percent of the time and, in some cases, will require a support team.

While the coding portion of an Agile project may be swift, the PO’s role could last two or more years, stretching from planning through implementation. It is critical that the new role is communicated to the rest of the agency team, and one of the best ways to do that is through a new PO job description.

Tool 2: Consider communication and change management support

Because the PO is often the key conduit of communication between the business and the development team, it is critical to consider how much communication might be required. For example, if a state is implementing new software in a county-administered system, the PO may need to both gather input from and communicate changes to all the county stakeholders—which could be scores of leaders across the state, all with different concerns and priorities.

In the absence of readily available information, there can be a tendency for everyone to call or email the PO directly. Instead, agencies should think strategically about which messages need to be communicated by the PO, and which directly by the leadership team or senior steering committee. Because the PO’s focus should be on technology delivery and adoption, it is typically important that change management, communication, process redesign, and training not all fall on this individual’s plate without proper support.

Moreover, even if the PO is a strong communicator on an individual level, she or he likely has little or no experience building a communication plan and even less capacity to execute that plan. Large-scale communications might include regular email updates, periodic conference calls, and training calls. If the new system will have impact on citizens, the press may have inquiries, and a PO can easily become overwhelmed by the amount of change management internally and externally. In these situations, establishing a separate communication and/or change management role and delegating those responsibilities to these professionals could alleviate the load on the PO. The PO would still be accountable for the communications that go out as well as the change management strategies that get implemented but would have the needed support.

Tool 3: Create a transparent project management organization (PMO)

The PMO in an Agile project can be large or small, run by a vendor or internally, and may play a critical or more secondary role. However it is established, a PMO website can leverage technology to make information accessible to key stakeholders, and the PMO can be a great way to communicate mass project updates. If stakeholders feel in the dark about the process, the negative impact of any problem could be multiplied.

Part of transparency is committing to the use of clear, jargon-free language in PMO reports. In too many cases, PMO reports end up going unread, such as the famed “TPS report” from the movie Office Space. Clear reporting from the PMO and other collaboration tools can streamline operations and serve as the central point for project progress, burndown rates, and so on.

Tool 4: Hold an open PO selection process

The PO role can often be seen as a plum assignment, showing the confidence that an organization is placing in the individual. For that reason, it is often best to invite interested parties to apply for the role. In the absence of a formal process, those not selected may feel overlooked or jealous. In addition, through a selection process, you may learn of others who are willing to step up to this challenge and thus might be able to play a supporting role. An open call for candidates, including external candidates, can help ensure the best candidate is selected while typically generating goodwill.

Even if the project sponsor has “the perfect person” in mind, it is often best to go through a process. Not only does it embody a principle of fair treatment, it also provides an opportunity to meet other possible contributors and explore key questions about the structure of the role.

Tool 5: Identify backup and coverage

The PO role is critical, but POs need vacation, get sick, and have unexpected emergencies, just like anyone else. Because of this, it is typically important that a backup be in place—someone who is close enough to the project to keep the wheels turning during brief absences. In larger projects, there might be a need to establish this position more permanently, as a deputy PO who can also help the PO in day-to-day activities.

Tool 6: Colocation and mobile support

Agile puts a high emphasis on regular, face-to-face communications. If possible, it may be best to colocate the business user group and development team. If that is not possible, POs often need space in both locations to accommodate the working hours of a vendor project team. Indeed, committing the resources to getting a good space for the team can be important, as public agencies often operate near capacity for space. In addition, it can help if the PO has access to mobile technologies such as a laptop and smartphone to enable close communication at all times. This may not be the standard approach for the government agency, but is key to enable the work demands of the PO.

Tool 7: Training

If the new PO needs training in Agile, a software language, or project management, try to get these trainings done prior to the project launch. Also, be prepared to commit training resources to the other Agile team members as well as to key members of the senior leadership team and business stakeholders with whom the Agile team may regularly interact, including the contracting office. Given the unique terminology of Agile (scrum master, velocity, story points), those without some training may feel excluded and resentful of the Agile team, setting up barriers to collaboration.

Table 1. lists the possible project features that will help POs achieve success.

Agile success comes with commitment

Why are more and more government entities looking to use Agile? Perhaps some have seen Agile deliver success in prior jobs in the private sector. Or perhaps government leaders have had a bad experience with Waterfall, one in which a big, thick document of requirements—often challenging to read, or at least open to different interpretations—was handed over to a development team, which then worked in isolation for months, only to deliver software that failed to satisfy user needs and hence required a long, laborious, contentious rewrite.

But for Agile to succeed, the public sector partner should be an active participant throughout the development process, with the PO playing a big role in that. The PO typically needs the support and attention of senior leaders; access to support for change management, communication, and training; and the ability to bridge the gap between users’ needs and the development team.