Context counts but whose?

The concept of tailoring has been referenced in all editions of the PMBOK® Guide but the topic starting receiving more coverage in the Sixth Edition and finally was given a full section in the most recent edition. But before we can start tailoring we need to answer the question of what context needs to be addressed.

External

Outside the performing and receiving organizations, the environment within which the project is being executed needs to be considered. These form the external portion of the Enterprise Environmental Factors (EEFs) which are frequently referenced in the PMBOK Guide.

The industry we are in will influence and constrain our approach. In the pharmaceutical industry, validation documentation for projects which are involved in the testing or production of products is required whereas in other industries, less formality might be needed.

What’s going on in the world also needs to be considered. The COVID-19 pandemic imposed requirements on teams to work in a dispersed manner even if they could have previously been co-located.

Organizational

The context of both the performing and receiving organizations will influence project approaches. Organizational Process Assets (OPAs) such as standards and policies apply, but also factors such as where stakeholders are located, funding availability, and what else is going on in the organizations needs to be considered. For example, running a project in a long-standing, large organization usually involves heavier governance and oversight than that for a startup.

The terms and conditions from contracts established between the performing and receiving organizations will also affect how the work is done. For example, while team members from the performing organization might have preferred to use one set of tools for managing their work flow, their contract with the receiving organization might specify the requirement to use an alternate tool set.

Team

Characteristics such as a team’s longevity, its culture, factors such as the level of psychological safety and trust within it, and its makeup will affect our tailoring approach.

We might want to encourage team members to become generalizing specialists but if some of the team members fall under a union contract which rigidly defines the type of work they can do, this might not be possible.

If the team is new and the team members have not had a chance to work together in the past, working agreements and handoff criteria might need to be more explicitly documented than for a long standing team.

Individual

We need to consider the context of each team member as well as that of our stakeholders.

One of the principles from the Manifesto for Agile Software Development is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”. But what happens if one or more of our team members are extremely introverted and are uncomfortable with prolonged face-to-face work? Similarly, we might want to do an experiment in pairing or mobbing, but if the individual personalities and preferences of team members don’t support this, the experiment might fail.

Information radiators such as a product canvas or a work board might be sufficient for most stakeholders to understand what’s going on but if one of our key stakeholders insists on getting more context about project status we might need to produce a status report or hold a regular meeting to meet their needs.

Context (at all levels) counts.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores)

Vigilance is vital to avoid velocity vices!

After daily coordination events (a.k.a. Scrums, standups or huddles), velocity might be the most misused tool by teams new to agile and the stakeholders supporting them. Used appropriately, it can help a team to understand how much work they can complete in a fixed amount of time and thus could be used to forecast when they might be done with a release. However, being able to do so requires that three critical prerequisites are met. If any of these are not, velocity is irrelevant.

The first requirement is that the team composition and capacity should be relatively stable. You might argue that if capacity has decreased, one could pro-rate velocity based on the decrease. This assumes that we have enough capability (skills and experience-wise) across the remaining team members to complete work items, albeit at a slower pace. In the real world, teams often rely on specialists and if any of those are missing, it might not be possible to complete certain work items.

The second prerequisite is that the team needs to be working on the same product. Change those and there is no guarantee that they can continue to complete work at the same pace unless the two products are very similar.

Finally, the relative uncertainty of upcoming work items should be less than or equal to that of recent previously completed work items. If complexity or uncertainty increases over time, velocity cannot be relied upon.

So assuming these three conditions are met, can we breathe a sigh of relief and freely use velocity?

Unfortunately there are still three ways in which velocity data can be abused by stakeholders.

1. Comparing velocity between teams. Regardless of whether you use story points, number of work items completed or some other method to calculate it, it is meaningless outside the context of a specific team working on a specific product. Using velocity as a performance measurement could encourage the wrong kind of behaviors such as neglecting quality, working an unsustainable pace or ignoring tangible business value delivered.
2. Calculating velocity at an individual team member level. Teams complete releases, individuals don’t. Measuring velocity at the team member level provides no real value and will just create destructive competitive behaviors within a team.
3. Assuming that velocity will continue to increase indefinitely. It is reasonable to expect that velocity will increase temporarily as a team evolves their way of working. However, it is unrealistic to expect that they can continue to speed up their pace of completing work unless there is either a significant change in the product, their delivery process or the team composition. Any such change would represent a different context which means that you couldn’t compare present to past velocity.

Just as with any tool, there is usually one right way and many wrong ways to use velocity.

Does your Product Owner have a high OQ?

An article from Harvard Business Review reminded me that becoming an effective Product Owner (PO) requires a lot more than interpersonal skills, empowerment, capacity and even product knowledge. In the article, the authors explained that leaders having a high level of Organizational Intelligence (OQ) stand a better chance of getting the organization to do what they want.

How can having a high OQ help a PO?

• They are able to see beyond titles or hierarchies to understand which stakeholders possess the real power when it comes to influencing product directions.
• They have a good grasp on the company’s strategic objectives which makes them able to “send messages that reinforce the strategy — and minimize other messaging.”
• They have a deep understanding of the core values and culture of the organization which helps them “foster an understanding, or ethos, of “who we are.””
• They will be more successful at influencing change vertically because of their understanding of how things get done. They know which battles are worth fighting and which are not. This can be especially crucial in the first few years of a shift to organizing around products.
• They will be better at helping the delivery team to connect the dots. Having a deep understanding of how teams within the company interact will make it easier for the PO to educate the team on the rationale for key decisions.
• When issues emerge, they are more likely to have built up goodwill with internal stakeholders to get their support in resolving the issues quickly.

This is one of the reasons why it is can be extremely difficult to fill the role well with someone who is external. A consultant or new hire might possess deep knowledge of the product and business domain, they should definitely have sufficient capacity to handle the heavy workload and they might even be exceptional at soft skills, but if they lack sufficient awareness of how things get done within their client’s organization, they are unlikely to be as effective as someone internal who might be lacking in the other areas.

Sometimes there may be nobody internal available who has sufficient capacity. If so, it is better to bring in an external player to back fill the “right” PO’s normal responsibilities. And what if you don’t have anyone with sufficient product knowledge which could be the case if the product or service is new to the organization? In such cases, it might be better to have an external player to support an internal PO while they are developing the necessary domain knowledge.

Building the right product requires a coalition of support across an organization, so don’t skimp on OQ when it comes time to pick a PO.