Posts Tagged With: Process compliance stupidity

How successful is your sprint planning?

Sprint planning is one of the standard events within the Scrum framework.

This ceremony or an adapted version has also been incorporated within other agile delivery frameworks which time-box the work of teams. The purpose of the ceremony is to align the team on what they will be working on during the upcoming sprint to ensure that their efforts are focused on delivering the highest priority work items in a quality manner while maintaining a sustainable pace of work.

Successful sprint planning lays the foundation for a successful sprint but this just completing the ceremony doesn’t mean it is delivering value.

Here are four common challenges which impact this critical ceremony.

Where is everybody?

Sprint planning is that singular opportunity to get everyone’s buy-in on what will be accomplished in the upcoming sprint. Partial participation means that decisions are being made on behalf of team members who are not in the room. That is likely to reduce their sense of ownership for the sprint backlog and increases the risk that work may be accepted which cannot be successfully delivered without heroics. While it might be convenient to conduct this ceremony first thing in the morning, the team should develop a sense of when they are likely to be fully present in mind and body and schedule it accordingly. Similarly, it is not advisable to start sprints on Mondays as that tends to be a more common day off than the middle days of the work week.

A lack of preparation

If the backlog doesn’t reflect the Product Owner’s priority, sprint planning is not the time to bring it up to date. Similarly, while highly mature teams are able to complete task identification, modeling, sizing or other preparatory activities during sprint planning, most others find that spending some effort in the previous sprint doing some look ahead planning will reduce the likelihood of running out of time in the ceremony or slicing off a sprint backlog with only a limited understanding of what needs to get done.

Appetite exceeds capability

Its normal for new teams to accept more work in a sprint backlog than they are realistically capable of delivering. However this gap between expected and actual velocity should reduce progressively sprint over sprint. When a lack of predictability regarding team capacity is not a blocker, teams which consistently take on more work than they are able to deliver are either demonstrating a lack of self-discipline or they lack the courage to educate autocratic external stakeholders on the dangers of accepting unrealistic commitments.

It’s my way or the highway

Whether it’s the Product Owner or a (supposedly) observing senior stakeholder, there’s no excuse for the development team being told how much work they will accept in a sprint.

Does your team experience any of these impediments? Is your team sufficiently self-aware and transparent such that these challenges are identified during retrospectives? If not, why not?


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

Why setup virtual PMOs and when should PM templates be standardized?

Dear reader, don’t be alarmed – this IS your regularly scheduled article!

I’d like to thank Sante Vergini for providing the inspiration for the first topic and the second one had been a splinter in my mind so I couldn’t wait till next week to write about it.

Why oh why would someone set up a virtual PMO?

In one of my past articles, I had written about the challenges of establishing and running virtual PMOs. I’m not referring to a PMO which is staffed by geographically distributed team members but rather one which has not been established as a staffed organizational entity. Virtual PMOs might be setup as a single individual spending a portion of their time delivering PMO services or a group of project management practitioners who commit some time to this.

Given that it might be difficult for a virtual entity to elevate organizational PM capability, mature project portfolio management practices or provide a meaningful delivery oversight function, why would organizations choose to go this way?

The most simple use case is when the leadership of a small functional organization-oriented company starts to realize the need to standardize or improve the company’s project management approach. The first person who starts to apply some project management discipline might be drafted into being a PMO of one.

Funding constraints could be another reason to establish a virtual PMO. The majority of PMOs are cost centers and the ROI for the investment in setting up and running a PMO might take a few years. If leadership recognizes the need to do something to improve project outcomes but funding is limited, one approach is to establish a community of PM practice and empower that group to design and implement change on a best effort basis.

Once bitten, twice shy might be another driver. Leadership teams which have lived through the fallout of a failed PMO might try to avoid the sunk costs of Groundhog Day syndrome by going the virtual route. Of course, if they haven’t addressed the root causes for why the original PMO failed, they shouldn’t expect miracles from a virtual approach.

A standard should be the means to a goal and not a goal unto itself

Repeatability is a good guideline when elevating organizational project management capability. But standardizing how information is captured needs to be carefully weighed against the benefits of tailoring and customization.

So what are some criteria which would justify standardizing a specific project management template?

If the information within it is going to be ingested by some automation to feed other processes then standardizing the format will improve processing efficiency and quality. If the consumers of the completed template are working with multiple project teams, there is a benefit in providing them with a consistent look and feel.

But if these conditions are not present, the emphasis should be on the quality of the content and not on the format or structure. If there is still a perceived benefit in standardization, effort should be invested in developing a template which can be easily populated, easily updated and presents what is required by its consumers in a minimally sufficient manner.

Anything more is waste.




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

Shouldn’t we ALL be agile project managers?

I always get a kick out of online discussions referencing agile project managers as if those are some special subset of the project management population!

Yes, there certainly are agile delivery methodologies and adaptive project lifecycles and some project managers might have gained greater experience in those, but what might some of the characteristics of an agile project manager be?

  • Their primary focus is on delivering value at the optimal pace of change absorption by their customers and key stakeholders.
  • They know that the secret sauce to project success is people first.
  • They don’t follow process for process sake and recognize that tailoring is as relevant to project practices as it is to clothing.
  • They embrace Robert K. Greenleaf’s teachings on servant leadership.
  • They recognize that a good solution today beats a great solution two years from now.
  • They accept that changes will occur and they steer their projects to take advantage of these changes rather than rigidly resisting them.
  • They favor face-to-face communication and embrace transparency in their reporting.
  • They promote a sustainable pace of work as they acknowledge that projects are marathons and not sprints.
  • They promote psychological safety within their teams and model the behavior they expect from their team members.
  • They instill a culture of continuous improvement in their teams by helping them reflect regularly on what’s working well and what could be tweaked.

The attributes in the list above should be applicable to any project manager in any industry managing projects using any type of lifecycle.

So why wouldn’t you want to be an agile project manager?


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

Blog at

%d bloggers like this: