Product Ownership In The Government Context

Product Ownership In The Government Context 2017-01-11T13:59:40-08:00

Being a PO in the government context presents some unique challenges.

Day Job
The largest challenge is often that as a Product Owner in the government sphere, you also have a “day job”, meaning that you also have a full slate of normal duties and responsibilities in addition to serving as a PO for your department’s project. It is very important that your time as an acting PO is supported by leadership and that you are allowed the time necessary to fully engage in the project you are working on.

Too Many Stakeholders
In theory, the PO is the liaison between the Agile team and the rest of the organization. Nobody but the PO should set the direction for the Agile team. When that organization is an entire state or national government, it is unrealistic for the PO to represent the millions of organizational stakeholders with 100% accuracy. This is a problem in all organizations, but is exacerbated because of the size and federated nature of government organizations. Untangling and de-conflicting all stakeholder priorities is not possible. The only answer for the government PO is to use their best judgement, demonstrating leadership amid ambiguity.

Legacy Process Drag
This means that you may be faced with stakeholders who are very attached to the way things are now, and to the historical or mythological reasons as to why things can’t and shouldn’t change. Legacy aligned stakeholders often have seniority or other levers of influence that can slow or disrupt the clear articulation of a single focused set of priorities. It will be the PO’s job to find a way to address this barrier.

Political Priority Soup
This is the circumstance in which a project may serve multiple departments or sub-bureaus, each of which will have a leader who has an agenda. It is sometimes tempting to allow each sub-group to set their own priorities. This can lead to having more than one top priority, since each sub-group will give the impression that their priority is the most important. If there exists – in fact or assumption – more than one top priority, there will be tears. Consensus must be made about a single set of priorities with a single #1 at the top. It is best to set those with the collective from the get go.

Name Dropping
This can happen anywhere, but has a rich tradition in the government context. This is the circumstance in which the team is setting priorities or finalizing a workflow, and a stakeholder utters, “I am glad we came to consensus on this but it’s really important to the Commissioner that we do what I want.” This is an example of an artifice that can create confusion and consternation instead of a satisfactory conclusion.

This practice can be averted by creating ground rules that discourage informal decision making. While informal discussions amongst the team and leadership is mostly a good and natural strategy for solving problems, it can become troublesome when big decisions that impact the team are made this way. As a PO you will work closely with the Scrum Master or Project Manager to create a communication and decision making scheme that execs and team members can follow without the need to invoke the names of higher powers.