Posts Tagged With: project decision making

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

How should I handle an agile-waterfall hybrid project?

A question which I’m frequently asked by learners attending my agile foundations courses is “I’m quite comfortable with what’s required for a waterfall project and what’s required for an agile project, but how do I plan and manage one where some of the scope is going to be delivered in a waterfall manner and some will be delivered using an agile approach?

I could plead the project management equivalent of the Fifth Amendment by answering “It depends!” which is a perfectly valid response given that the context of such hybrid projects varies widely.

In some projects, there is a very clear delineation between the type of deliverables being produced with each approach and there is limited direct integration between these deliverables. For example, technology deliverables might be completed in an agile manner whereas change management deliverables such as training collateral get produced in a traditional manner. In others, deliverables themselves are produced in a hybrid manner. For example, the web portion of a technology solution might be produced using agile methods, but the back end integration with a legacy system needs to be done in a traditional manner.

Another attribute which influences this is an understanding of who is delivering which work streams. Are they all being produced internally, or is a vendor responsible for either the agile or the traditional deliverables?

We also need to be conscious of the relative effort, complexity or scale of each work stream. A project where 95% of the deliverables are produced in a traditional manner will need to be planned and managed in a different fashion than one where the bulk of the scope will follow an agile delivery approach.

Things to consider when faced with such a hybrid project are:

  1. Orchestrating delivery cadence from each work stream to ensure that consuming work streams are not incurring prolonged delays in receiving components from providing ones. This can be a challenge when an agile work stream has dependencies on a waterfall work stream. On the other hand, if an agile work stream is delivering components to a waterfall one, there is an increased potential of component inventory buildup which is wasteful and could increase the likelihood of rework.
  2. Defining a common set of ground rules is important to avoid creating “us and them” rifts between the work stream teams. For example, if the agile work streams are able to use information radiators or other barely sufficient methods of communicating with stakeholders, figure out how the traditional work stream teams can do the same.
  3. Make the life of your approvers and control partners easier by coming up with a common method of capturing key information which they will need in order to bless your project. Requirements capture can be challenging in a hybrid situation as agile teams might prefer to use collaborative tooling such as Jira whereas traditional teams might want to use a business requirements document. Managing reviews and signoffs will be difficult, especially when the outcomes of each work stream are tightly integrated, if you don’t settle on a common approach.
  4. Finally, agile mindset and behavior need to prevail across the entire team and not just the agile work streams.

Purists will be shuddering while reading this while pragmatic realists are likely nodding their heads in recognition of how often a hybrid scenario occurs, especially in large organizations where the large variety of contexts eliminates our ability to apply a single methodology to all projects. When it comes to managing such projects a key lesson (plagiarizing Malcom X) is not to preach integration while practicing segregation!

 

Categories: Agile, Project Management | Tags: , , | 2 Comments

Avoiding groupthink on long-lived teams

Long-lived teams are often presented as being superior to their temporary counterparts. The benefits of longevity include the avoidance of wasteful forming-storming-norming cycles, higher levels of trust and psychological safety within the team and a more accurate understanding of what someone means when they communicate with us.

But there is a potential downside to persistent teams which can erode many of these benefits: groupthink.

Groupthink usually refers to a situation where team members prioritize consensus over the quality of a given decision or outcome. We might all disagree with Bob’s recommendation on how to address a project issue, but we value the harmony of the group over the mediocrity of his approach and hence we don’t challenge it. According to Irving Janis, the social psychologist who is credited with introducing the term, groupthink tends to occur most often where there are high degrees of cohesiveness, external threats, difficult decisions or isolation of the team from others. These factors are often found on long-lived teams.

So how can we avoid groupthink on long-lived teams?

One countermeasure might be to use Delphi or a similar method of anonymously or simultaneously gathering input from the team. This will reduce the likelihood of any one team member winning a “first to speak” advantage and will provide a structured approach to surface and discuss differing viewpoints.

Another option is to have the group nominate one team member to act as a devil’s advocate. This selection should be made on a per decision basis. Since everyone knows that this team member is responsible for finding weaknesses within a decision it eliminates their fear of being perceived as disruptive. Care needs to be taken in selecting the right team member to play this role. Someone who is likely to have significant interest in the outcomes of a decision might not be the best candidate as they might consciously or unconsciously disqualify the group’s approach to further their own path of action.

Have the foresight to bring someone in from the outside who has no stake in the outcome. This approach can replace the previous suggestion if team members feel that none of them can impartially play the role of devil’s advocate. This method has its own challenges as it might take some effort for the outsider to gain sufficient context to be an effective contributor to the decision.

Finally, breaking the team into two independent groups and having each group develop a recommendation is a very explicit method of eliminating groupthink. Of course, this requires a team which is large enough that such a sub-division is possible. If this approach is used more than once, it is a good idea to have different people in each group for each distinct decision.

When all think alike, the no one is thinking – Walter Lippman

 

 

Categories: Agile, Project Management | Tags: , , , | 2 Comments

Blog at WordPress.com.

%d bloggers like this: