Process Peeves

Thoughts on simple optimizations that could make daily processes better…

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.

 

 

 

Advertisements
Categories: Process Peeves, Project Management, Project Portfolio 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

All form and no (agile) substance?

Plus ça change, plus c’est la même chose

Jean-Baptiste Alphonse Karr’s warning reminds us that it is very easy to ignore the Manifesto for Agile Software Development’s value statements.

We might have done away with heavy project governance, premature or excessive planning, and documentation for documentation’s sake, but if we don’t remind ourselves why our team performs specific agile ceremonies, we are no better than our brethren toiling under the burden of traditional, one size fits all delivery practices.

Let’s start with sprints. Short time horizons should focus our efforts towards delivering value early and regularly while having fixed time boxes enables forecasting when we should be able to complete a release. But if we start treating sprints as phases (e.g. development, testing) or we batch work items within sprints in a waterfall manner, we haven’t really gained benefits from this approach. Similarly, if we don’t respect sprint end dates or we regularly modify the duration of our sprints we can’t forecast effectively.

How about your daily standups or scrums? These are meant to serve as micro-planning opportunities to align team members towards accomplishing sprint goals. They also provide an opportunity to surface blockers in a transparent, safe fashion to ensure these get resolved in an efficient and effective manner. But if team members are absent, we don’t start or end on time, one person monopolizes the discussion, or they turn into status meetings, why hold them at all?

Velocity enables teams to assess their throughput sprint over sprint. Used correctly and with the right underlying discipline on work sizing and backlog management, velocity can help a team forecast. But obsessing over velocity is as bad as focusing on percentage work complete in traditional approaches. When abused velocity leads to progressively reducing quality, erosion of team morale and unhealthy comparisons between team members or teams.

Showcases or demoes give a regular opportunity for key stakeholders to view what has been completed, to provide feedback to ensure that what is delivered meets customer needs, to maintain sponsor commitment and to provide a forum for visible recognition of the team’s hard work. But holding these ceremonies when there is nothing meaningful to demonstrate provides limited benefit to the invitees. Having the agile lead or other team member be the only person conducting the demoes doesn’t give everyone a chance to have their day of glory. And having team members get defensive when constructive feedback is provided about a feature which doesn’t quite hit the mark is just going to further the gap between the delivery team and the customer.

Meet the new boss, same as the old boss” – Pete Townshend

 

 

 

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

Blog at WordPress.com.

%d bloggers like this: