Problems with your Product Owner?

Scott Adams continues to hit the mark when it comes to the dysfunctions plaguing the corporate world. His latest Dilbert comic strip inspired me to write about a common challenge facing those organizations who are moving from a project-centric to a product-centric delivery approach, namely developing effective product owners.

The funny thing is that this is not a new role – go back a couple of decades and it was common to have senior managers responsible for making the majority of decisions regarding products or capabilities. As organizations shifted away from functional to matrix models, such decision-making became diffused. Also, as a company’s size grows, the authority for product decisions often moves up the corporate ladder to executives who are responsible for multiple products.

We tend to think of the product owner role in the context of agile delivery but it can also apply to traditional delivery approaches too. A key difference is that product owner ineffectiveness creates greater impact on agile projects than on traditional ones.

So what are the most prevalent peeves we have with product owners?

I’ve previously identified Capability, Commitment and Capacity as three characteristics of effective team members. Gaps in any one of these areas will translate into product quality, team productivity or morale issues.

These attributes are also important in product owners.

Managers who possess strategic vision, political influence and knowledge of a product are often unavailable to be committed to the extent required to effectively support a delivery team. Faced with this dilemma, executives usually will either still commit these managers or will have them appoint proxies.

With the former scenario, delivery teams enjoy good quality decision making but are starved for the product owner’s attention. Decisions which could be made on the spot get delayed. If the team waits for decisions to be made, productivity and eventually morale suffers whereas if they try to proceed based on their knowledge the risk of rework increases.

Proxy product owners might not have the knowledge, vision or influence required to make good quality decisions or to have those decisions stick. What sometimes occurs is that significant decisions need to be blessed by one or more senior leaders which increases the risk of delays. Proxy product owners might also not enjoy having accountability without authority and their commitment to this role wanes over time.

But there’s one more characteristic – Collaboration.

Let’s say we have a product owner who has the first three C’s in spades but they don’t collaborate well with other senior stakeholders. In most organizations there are control partners whose input needs to be incorporated into product decision making to keep the company safe. The solution lead for the product should also have a voice to ensure that technical debt or other sustainability considerations don’t impact the organization.

If the product owner is not able to effectively collaborate to distill these many voices into one, they risk alienating key partners or making decisions which will hurt the company in the long run. While the role has authority over product decision making, this should not be done in an autocratic manner.

The introduction of the product owner role is an ideal way to streamline decision making and develop future leaders but neglect the four C’s of Collaboration, Capability, Commitment and Capacity at your organization’s peril!

Advertisements
Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 1 Comment

Finding the right retrospective rhythm

What’s the appropriate frequency for conducting retrospectives? If you follow the Scrum methodology or a hybrid of it, you’ll likely say at the end of every sprint, once the sprint review, showcase or demo has taken place.

For teams which are learning to be agile, that is the right answer. It takes a few sprints for a new team to develop the mutual trust and psychological safety required to have a productive retrospective. In those early sprints, there might be a reluctance to identify problems for fear of offending team members, a tendency to identify symptoms rather than real issues or to generate a long list of “did wells” and “do betters”. Team velocity has also not stabilized and hence there is ample opportunity to increase it through incremental improvement on each sprint.

But what happens once a team has worked together for many sprints?

Answering the same questions sprint-over-sprint gets old really fast. To try to resolve this, the agile community has been very creative at coming up with alternate methods of eliciting valuable input using materials such as Lego bricks or Play-Doh. But while such variety might make for a fun team activity and should reduce the potential for team member disengagement, will repeating this ceremony every sprint always generate value? And if it doesn’t, why are we doing it?

On projects where the team has gelled and their delivery process is in control, there is often a natural transition from team level continuous improvement to team members practicing personal kaizen.

But this shouldn’t mean that we stop doing retrospectives. To do so would be to repeat that mistake of traditional lessons learned practices of identifying them too late in the lifecycle to provide much value to the originating project. For teams which are delivering change every few sprints, a release might provide a good opportunity to hold a productive retrospective, but that might still not be often enough.

Team self-awareness needs to be at a relatively high level so that an individual team member can identify the benefit of conducting a retrospective, but to help bring some consistency to the process, the team could proactively define trigger events. Examples of such triggers could include velocity falling outside of the team’s expectations, quality dramatically improving or dropping, unexpected feedback or outcomes from a sprint review, or the departure or arrival of a team member.

So what is the right retrospective rhythm?

Just in time to generate value for subsequent delivery efforts.

 

 

Categories: Agile, Process Peeves, Project Management | Tags: , , | 1 Comment

How are you resolving your agile transformation blockers?

Teams leading agile transformations can encounter multiple challenges along their journey including changing the mindsets of senior and mid-level managers, transitioning from a focus on specialists to developing generalizing specialists, educating and effectively engaging delivery or control partners and reducing the time and effort required to deploy deliverables once they’ve been deemed production ready. Worse yet, it can sometimes feel like a game of Whac-a-Mole – as soon as your team resolves one hurdle then another two surface.

How about being agile with your transformation!

Treat each of these blockers as a work item in a backlog. Collaborate with stakeholders to identify appropriate acceptance criteria to help you know when you’ve successfully resolved the issue. Size the work items with your team. As with all preliminary estimates in agile don’t aim for precision but rather for consistency. T-shirt size them or if you feel creative use an alternative fun sizing taxonomy (Decepticon-sizing?).

Prioritization will be a challenge. Just like managing a backlog of product requirements, it’s rarely as simple as letting business value be the sole determinant of priority. Many of these hurdles will be interdependent. You might also want to incorporate relative uncertainty into the ranking process by tackling higher risk and impact hurdles first.

Once you’ve prioritized these blockers at a high-level your team should decide whether it is worth disaggregating them into smaller hurdles. Techniques such as story mapping could then be utilized to help you create a release plan for resolving the issues.

Now comes the tricky part – socializing the plan with your senior stakeholders. Assuming they accept the list of blockers and their relative priority you will want to share it with delivery teams and control partners across the organization. This will increase their confidence in the transformation as well as helping to manage their expectations regarding the resolution timeframes for specific blockers.

A critical step is to adapt and evolve the plan as your transformation progresses but don’t obsess over creating the ideal plan. As new blockers get identified by delivery teams, size them, prioritize them and add them to the backlog. Use information radiators to share status. For example, you could post a list of which hurdles are being actively worked on, which ones are “on deck”, and a burn-up chart with an up-to-date forecasts of when the backlog will be cleared. Your team should also decide whether a sprint-based or lean lifecycle makes sense given their capacity and maturity.

Resolving a backlog of organization blockers can seem an insurmountable task but take the opportunity to increase buy-in and provide a showcase for the benefits of being agile.

 

 

 

 

Categories: Agile, Facilitating Organization Change | Tags: , | 2 Comments

Create a free website or blog at WordPress.com.

%d bloggers like this: