Easy in theory, difficult in practice

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


Recent Posts

What are some of the underlying causes of ineffective project risk management?

PMI plus Disciplined Agile might be a marriage made in Heaven

How open are YOU to changing your launch plans?

Does closeout vary between projects following an adaptive rather than a predictive life cycle?

Our stories aren't getting done!

PMI plus Disciplined Agile might be a marriage made in Heaven

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.

Posted on: September 08, 2019 07:00 AM | Permalink | Comments (11)

Does closeout vary between projects following an adaptive rather than a predictive life cycle?

Categories: Agile, Project Management

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.

Posted on: August 25, 2019 11:08 AM | Permalink | Comments (4)

Our stories aren't getting done!

Categories: Agile, Project Management

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.


Posted on: August 18, 2019 10:41 AM | Permalink | Comments (4)

What challenges do distributed teams pose to others?

Face-to-face communication around a shared modeling surface such as a whiteboard is considered to be a highly effective method of creating shared understanding. When team members are distributed, collaboration tools can help with reducing misunderstandings and miscommunications between team members but can't fully eliminate those.

But what about the impacts of distribution on other roles such as agile leads or senior stakeholders?

To an outsider, an agile lead's visible contribution in the early stages of team formation might be the facilitation of agile ceremonies but this is really just the tip of the iceberg. If the team is maturing, any team member should be able to run ceremonies. The greater value brought by an agile lead in such cases occurs outside of ceremonies, through actions such as suggesting opportunities for increased collaboration between team members, coaching individual team members and working with key stakeholders outside of the team.

With co-located teams, agile leads often identify coaching opportunities osmotically by just being present with the team. A casual comment might spur an agile lead to have a conversation which might avoid hours of unnecessary work. But with distributed teams, unless the agile lead is plugged into all the conversations taking place between team members and with external stakeholders, there is an increased likelihood of missing a coaching moment or being unable to help the team to address a blocker in a timely manner.

Persistent group chat tools such as Slack or Microsoft Teams can help the agile lead to be somewhat aware of what's going on, but it is rare that all members of a team would conduct all of their interactions through these platforms. Online work management tools such as JIRA or Rally can capture significant updates for the team's work items, but it is rare that an agile lead will review all changes to those work items even if team members have been diligent about regularly updating them.

In such cases, eliminating or reducing the level of multitasking will be critical as the impacts of context switching are compounded with distributed team members.

With senior stakeholders, even if good information radiators have been constructed and published, lacking in-person access to the team might increase the number of ad hoc requests for updates as there is less opportunity for them to observe how the work is being done. It might also put a greater emphasis on regular showcases or frequent product reviews as the primary method of soliciting product feedback rather than the preferred ability to drop by and see the latest build as the need arises. This might increase the time it takes these stakeholders to begin to trust the team's capabilities. Similarly, because  team members won't have regular in-person contact with these senior stakeholders, they may also take more time to start to trust them. Bringing the team together with key senior stakeholders on a periodic basis is one way to address these concerns, but this can be an expensive proposition.

With ever increasing needs to tap into dispersed skill sets and to support flexible working arrangements for team members, distributed teaming is here to stay. Acknowledging that more effort will need to be spent overcoming distance challenges is an important step to managing expectations with this way of working.

Posted on: August 04, 2019 07:00 AM | Permalink | Comments (4)

What can we do when a team member isn't pulling their weight?

One of the learners in a class I taught asked me how self-organizing teams would handle the situation where a single team member is not performing a fair share of the work.

In a traditional, push-based work assignment model, this issue can also occur. Usually whoever has pushed the work onto the low performer will follow up with them in a timely manner and take direct steps to ensure that performance improves, the work gets re-balanced or the team member is replaced.

But with a pull-based approach where individual team members sign up for work items as capacity frees up and where the focus is on how much is getting completed by the team as a whole, the concern is that someone could take advantage of this by letting their peers take on the more challenging work items leaving them with a relatively lighter work load. From the outside, it would appear that the work is getting done but the contribution imbalance will be less evident.

On a mature self-organized team this is not likely to be an ongoing concern. Team members recognize the importance of demonstrating courage and showing respect for the team and will exert the necessary social pressure on the low performer so that they will either feel embarrassed and start to improve or will be transferred out of the team. If the team uses agile ceremonies such as sprint planning, daily standups or retrospectives, these provide an opportunity to provide feedback with radical candor to the low performer.

But on those teams which are relatively new to working in this manner, the team members might not possess the confidence to openly discuss or challenge such dysfunctions. Passive aggressive behavior might occur such as remaining silent during a retrospective and complaining around the water cooler afterwards.

In such cases, the agile lead or Scrum Master might need to get involved to eliminate the impediment. This intervention could start in a subtle manner such as asking the individual at a daily standup if they feel comfortable with their workload for the day compared with their team members, or "seeding" the conversation during a retrospective when the topic turns to what could be improved. They might encourage other team members to ask the individual to give them a hand with their work items or to conduct a non-solo work experiment (e.g. pair programming).

If this soft approach doesn't work, the Scrum Master may have to more drastic steps such as confronting the individual one-on-one, speaking with their manager or some other type of escalation.

Deferring decision making to the Last Responsible Moment is a lean principle. While a Scrum Master shouldn't intervene if the rest of the team can address an issue for themselves, they should have the judgment to know when they will need to take a more direct approach.


Posted on: July 28, 2019 07:00 AM | Permalink | Comments (14)

"A fanatic is one who can't change his mind and won't change the subject."

- Winston Churchill



Vendor Events

See all Vendor Events