Easy in theory, difficult in practice

The announcement of the acquisition of Disciplined Agile (DA) by PMI is almost a month old so I thought I would share my thoughts on it.

There is no doubt that PMI has been flirting with agile progressively over the past decade. The launch of the PMI-ACP credential, the addition of adaptive life cycle considerations to the PMBOK® Guide, Sixth Edition and the release of the Agile Practice Guide were all signs of this growing interest.

However, PMI suffers from being perceived as a champion of bureaucratic, traditional approaches to business value delivery which has generated a fair bit of cynicism from the agile community. The partnership with the Agile Alliance which led to the development and publication of the Agile Practice Guide were viewed by some as a unhealthy dalliance or a marriage of convenience.

Correcting perceptions and developing sufficient intellectual property (IP) would have taken PMI many years to do organically so acquiring legitimate thought leadership, credibility and IP was the better strategic move. A key decision was to choose either a method-centric (e.g. SAFe, LeSS) or method-agnostic (e.g. Disciplined Agile, Modern Agile) organization. Given the need to address a global market with varied needs, agnosticism won out.

There are a number of potential advantages to PMI, DA and practitioners.

PMI now has the ability to incorporate the significant intellectual property of DA within their knowledge base and by doing so, enhance the value proposition of their standards and practice guides. While tailoring considerations were minimally explored in the PMBOK® Guide, Sixth Edition, they can now go much deeper by leveraging the DA process decision-making framework. PMI can also expand the breadth of their credentials and by doing so, will add credibility to the existing DA ones. Given the strategic relationships which PMI's senior leadership has forged with major global corporations, this acquisition will open doors for DA which might not have been possible otherwise which in turn might accelerate the evolution of DA. It is also an opportunity for the DA framework to go beyond technology delivery.

But there are some risks, including the dilution of thought leadership, the obsolescence of existing credentials and the risk of PMI actively competing with partners (e.g. Registered Education Providers). PMI might also make the mistake of not fully integrating DA into their offerings which would limit the benefits realized from this acquisition.

If there is a single piece of advice I'd like to pass along to PMI & DA, it is from Audrey Hepburn: “If I get married, I want to be very married.”

During the last week PMI announced that, based on the feedback they had received from stakeholders, they would be delaying the significant changes to the Project Management Professional (PMP)® certification exam which had originally planned to be launched in mid-December 2019 to July 1, 2020.

When I first read this, I felt a burst of vicarious relief for those exam candidates who were likely experiencing a lot of stress with the original date.

I have no doubt that this was the right decision for PMI to take.

The proposed changes to the exam are likely to be more significant than others made over the past decade. With the last batch of changes to the exam having been implemented in March 2018, a significant update within two years will not only cause candidates angst but will also reduce the return on investment for the study materials which training companies would have so recently updated.

After further reflection I realized there are some good lessons in change management with this decision:

• As a not-for-profit association, stakeholder satisfaction may be more crucial to PMI than if they were a for profit entity, but regardless, they have been very proactive at communicating both the rationale and the scope of proposed changes even though these announcements were likely to upset certain the stakeholders. Often, while considering a disruptive change, our temptation might be to avoid communicating anything until there is a full understanding about the impacts but that usually won't give stakeholders sufficient time to react to the information.
• They were open to hearing negative feedback about the changes. It's easy for leaders to say that they are willing to hear criticism about a change they have championed but much harder to take it when it happens.
• PMI decision makers were willing to make a change late in the game for the right reasons. I'm used to seeing leaders' appetite for change drop drastically as a proposed implementation date draws near. This makes sense as change deliverables need to be sufficiently stable before a launch date, but if there is evidence that the benefits of sticking to a date will be outweighed by the impacts of a premature launch, leaders should be willing to accept some near term embarrassment in order to realize a more sustainable outcome.

I have no idea who was the decision maker at PMI who pushed for this delay to the launch date, but this demonstrates the sort of good judgment which we should demand from change leaders.

Completion of a project usually focuses on financial and administrative activities such as transitioning verified and accepted deliverables to customers, getting final sign off on the project, closing open contracts, recognizing team accomplishments, survey stakeholder satisfaction, archiving key project outputs and so on.

But with an adaptive life cycle, the approach taken when performing certain activities might vary. Here are two examples of this:

• It is common to hold a lessons (to be) learned session at the very end of a project. With most traditional approaches, there would usually be few times when the team and key stakeholders might have got together over the life of the project to do this, so this can be a fairly onerous process of locating the right participants (many of whom might have moved on to other projects much earlier), identifying learnings, prioritizing them and distilling them into (hopefully!) useful knowledge for future projects. On projects which have followed an agile life cycle, there should have been multiple, regular feedback loops for both the product and team process over the life of the project and these can be used as a starting point for curation.
• Project closeout often involves identifying any remaining open work items such as defects or enhancements which were not completed by the team during the life of the project and transitioning ownership of those to the right stakeholders. With traditional projects, there may not be a consistent approach to such transitions, centralized tracking of the exceptions might not be in place (which means some might be missed) and it may be challenging to identify who is best suited to owning specific items. With projects using an adaptive life cycle, whatever is left in the product backlog would be transitioned and, in the absence of any other owners, the product owner is usually the right role to own them.
• With traditional projects, archiving of project documents is frequently done for contractual or compliance purposes. While this is also true on projects following an agile life cycle, if key project delivery information such as requirements or design specifications were captured within online information repositories, it is a good idea to take a snapshot of this content for archival purposes as we would expect to continue to evolve this content for future projects in the same web pages.

So is there any difference to how projects which were managed using an adaptive or agile life cycle would end compared to those following a traditional or predictive one? At a high level, no, but our approach to specific procedures should always be tailored to fit the context of the life cycle used to deliver it.

It is common to see teams new to those agile frameworks which use time boxes struggling to define product backlog items small enough to get completed within a sprint and still represent value. If they have been used to traditional, predictive delivery approaches, they would have been encouraged to decompose scope down to a manageable level of control, but these work packages would still usually be larger than what is expected of a sprint backlog item.

Some teams respond to this challenge by using long sprints.

While this gives them the opportunity to complete more work within a sprint, it has downsides. The team might be inclined to batch their work by completing one stage of their delivery process for a number of sprint backlog items rather than completing these items individually over the life of the sprint. Long sprints might also reduce the team's inclination to sufficiently refine and split stories.

Other teams try to avoid the challenge entirely by skipping sprints in favor of a continuous flow approach. A mature team can effectively use this delivery method, but new teams without coaching support might end up with an ever-growing work-in-progress backlog as work commences on a work item but as soon as it gets blocked another work item gets pulled.

Shorter sprints make it harder for a team to ignore the reasons for why their work items aren't getting done, including:

• Vagueness or ambiguity with the work item. If the team accepts the work item into a sprint without shared understanding on what is required, significant effort can be spent in gaining that understanding or in doing rework if their original understanding wasn't complete. This can often be addressed through effective look ahead planning a sprint before that work item is accepted by the team.
• Underestimating the size of the work item. While occasional under or overestimation are common cause variations for mature teams working on a product which they are comfortable with, chronic underestimation might point to over-optimism or a lack of sufficient diversity within the team.
• Lots of external dependencies. The effort of the team for work items might be manageable but if they are relying on external partners for some of the work, they may not have sufficient influence over these partners to ensure that the work can get completed on time. If this is the case for a few product backlog items, it might be something they have to live with in the near term, but if it is happening every sprint, it shows they are not truly a "whole" team.
• Excessive multitasking. Whether it is distractions from outside the team's product work or it is taking on multiple work items at the same time, context-switching can rob the team of the ability to complete a single work item in a short amount of time.

While there is no silver bullet to deal with these causes, if a team remains true to the pillars of inspection and adaptation, their ability to deliver consistently should improve over time.

While the relative level of formal authority vested in a project manager is greater in project-oriented (formerly projectized) organization structures than in matrix ones, the downside of this authority is that the project manager will spend much more time on people management administrative activities such as performance evaluations, hiring and supporting their professional development. While this is important work, it doesn't directly relate to the management of their projects and they might perceive it as a distraction.

In addition, in those organizations which are purely project-oriented (i.e. everything they do is project work with no functional or matrix structures to be found elsewhere within their walls), when projects end, if the team members who were contributing to them cannot be deployed to different projects then they may find themselves out of a job which is likely to stress their project managers even more at the very time when they are trying to line up other projects for themselves.

But there is a silver lining to this people management cloud.

Having these responsibilities will force the project manager to learn about the hopes, dreams and career aspirations of their direct reports. This should provide them with a greater ability to enable them to connect the team members' individual purposes to the success objectives of the project. They will also be better positioned to understand the competencies over which their staff wish to gain mastery which they can use to identify opportunities for personal development for these team members. Finally, even as project managers working in matrix structures will need to learn how to effective delegate, empowering their staff to work with autonomy is even more critical when there is a formal reporting relationship in place.

Project managers in project-oriented organizations might chafe at the additional responsibilities they have to shoulder, but these also give them more power to inspire their team members.