Project Management

Easy in theory, difficult in practice

by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Let's flatten five agile fallacies!

Planning for those project disasters that no one wants to think about

What's the link between emotional intelligence and psychological safety?

How do you build your brand as a project manager?

Vigilance is vital to avoid velocity vices!

Let's flatten five agile fallacies!

Categories: Agile, Project Management

In 2015 I wrote an article intending to debunk some common myths about project management. Like many of you, I spent a reasonable amount of time during my first few years participating in online forums correcting agile misconceptions. Unfortunately, just like lopping heads off the Hydra, every time I'd address one myth, a short time later it would re-emerge. Recognizing the futility of trying to permanently suppress fallacies, I stopped responding to such discussions. However, as I would still like to help, writing an article on five of the most common agile myths will give me a reference to provide to folks in the future.

Agile projects and agile methodologies

There's no such thing. You can have projects which get delivered by teams using an adaptive life cycle or in which the team elects to use certain agile tools and techniques but unless the project itself is suddenly going to become sentient, it can't be agile. Agile is not a method (which is what most folks mean when they use the word "methodology"). A team or a company can create a delivery method based on agile values, principles and practices but that is just a single instance of an infinite variety of ways of delivering projects.

We need to do agile

Agile is an adjective, not a noun. Becoming (more) agile should also never be the goal of a team or organization but rather a means to achieving one or more goals. Make it a goal unto itself and the downstream impacts might result in worse outcomes than your current state.

Agile started with the Manifesto

The Manifesto for Agile Software Development is a curation of specific software delivery values and principles. None of these values and principles were revolutionary or novel in 2001 as they had all been identified before in one body of knowledge or another. Concepts, tools and techniques associated with agile have been used for decades and many popular delivery frameworks such as Scrum and XP were published before the Manifesto was written.

To be agile, you must be/have/do "X"

Whether it is sprints, story points, user stories, product owners, servant leadership or any one of a myriad of other roles, tools, techniques and buzz words, the agile community has become really efficient at dividing and conquering itself. Being agile needs to be assessed by outcomes and not merely by how those outcomes were achieved otherwise you risk sliding down the slippery slope to cargo cult.

Agile delivery is better (or worse) than waterfall

Context counts. There is a wide range of possible life cycle choices from fully adaptive to full predictive and very few projects fit cleanly at one end or another of the spectrum. Profiling a project to learn where it falls along this continuum is a critical step for teams to take when tailoring their approach to find better ways of delivering that specific project.

Any others I've missed? Feel free to respond in the comments and I'll add them to the list!

Posted on: September 13, 2020 07:00 AM | Permalink | Comments (12)

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.

Posted on: August 16, 2020 07:00 AM | Permalink | Comments (4)

All hands abandon plans!

Articles have been written about the importance of doing just enough planning to develop confidence in what we are proposing to do as well as the perils of either too much or too little planning.

But even a good enough plan can become obsolete at some point and we need the wisdom to know when it is time to jettison it.

A common portfolio management anti-pattern is the inability of gatekeepers to terminate low value projects in a timely manner. There are many causes for this, but one is the inability to easily write off project sunk costs. The same can be said of plans - some teams and especially their leaders can become so enamored with their plans that their confirmation biases cause them to ignore clear evidence that those plans are no longer valid.

So what are some signs that a project plan needs to be punted?

  1. The primary success criterion can no longer be achieved. All project constraints are important, but some have to be more important than others otherwise it will not be possible to develop realistic plans and to modify those plans as things change. If the primary objective can't be achieved with our current approach, then we need to change our approach.
  2. A sufficiently material unknown-unknown risk is realized whose impact cannot be absorbed leading to the first condition above. I'm a big fan of the Die Hard movies, and the villain of the first film, Hans Gruber, commits the fatal mistake of underestimating John McClane's abilities to derail his exquisitely designed plan to steal the bearer bonds from the Nakatomi building. His hubris is well summed up in the following exchange: Hans "We do NOT alter the plan!" Karl: "And, if HE alters it?"
  3. A fundamental planning assumption is proven to be invalid. While planning the 9/11 attacks, the terrorists made the assumption that the passengers on board the hijacked flights wouldn't have the courage to resist when faced with armed attackers. This assumption was proven wrong on United flight 93 after the passengers learned what had happened to the earlier doomed flights that morning.

But is it sufficient for us to recognize that a plan is no longer valid? No, because this realization needs to be effectively communicated in a timely manner such that a new plan can be formulated. Doing this requires not only courage but also a sufficient level of psychological safety within the team to reduce the likelihood of team members choosing short-term conflict avoidance over long-term pain. Naohiro Masuda's management of the crisis at the Fukashima Daini nuclear plant in March 2011 provides a good example of how leaders might behave when planning under pressure.

Planning is essential, the value of plans is ephemeral, so let's treat them that way!

Posted on: June 28, 2020 07:00 AM | Permalink | Comments (5)

Does your Product Owner have a high OQ?

Categories: Agile

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.

Posted on: June 21, 2020 07:00 AM | Permalink | Comments (6)

“Organize Around Products/Services” is a great addition to the Disciplined Agile principles!

The original seven Disciplined Agile (DA) principles were recently refactored and as part of this refactoring, a principle was added: "Organize Around Products/Services".

While it is just one of the eight principles, this new one aligns very well with lean thinking. It also addresses many challenges which leadership teams experience with agile transformations. Such transformations require change to happen in not only the delivery teams within an enterprise, but also supporting functions such as finance, human resources, operations and procurement.

Some benefits of a product or service-centric organization include:

  • A reduced likelihood of the "throw it over the wall" syndrome. When delivery teams are responsible for not just the enhancements to their products or services but also the resolution of escaped defects there is more skin in the game for them to build higher quality solutions. This also encourages teams to take a holistic view of a solution and not just its usability and functionality.
  • Securing funding is less challenging when we organize around solutions rather than the individual projects to evolve those solutions. Based on the strategic value of the product or service, governance leaders should be able to allocate a tranche of funding for a time period such as a quarter or a fiscal year. That funding will determine how much value can be added into the solution over that time period.
  • Better team cohesion and a reduction in the waste that comes with repeatedly going through the Forming-Storming-Norming (and Adjourning) phases of team development. When we organize around solutions, the delivery team remains together until that product or service is no longer needed by the organization. Prerequisites for high performing teams such as psychological safety and radical candor are more likely to develop and be strengthened within long-standing teams rather than short-lived ones. The team would also gain greater knowledge of the business domain which would increase the value they can provide to stakeholders while they are enhancing their assigned products or services.
  • It addresses the inherent problem that how we structure an organization is not how the work on products or services is actually accomplished.

This is not to say that organizations don't need project management as the hard and soft tools of the profession are still critical to implementing successful change. There will always be some changes which are "one and done" and those will remain fair game for project teams. Nothing would prevent product/service owners from organizing the allocation of funds within their annual allotment to projects if that makes the management of this funding easier for them.

But if we are looking to increase alignment, organizing around products or services is a good way to cut through the silo thinking which develops when we are organized by function or capability.

Posted on: June 07, 2020 08:32 AM | Permalink | Comments (5)
ADVERTISEMENTS

"If you are patient in a moment of anger, you will escape a hundred days of sorrow."

- Chinese Proverb

ADVERTISEMENT

Sponsors