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.”
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.
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.
Two articles caught my attention this morning so I thought I'd connect the dots between them in this week's article.
The first article indicates that the Microsoft Teams collaboration support tool has passed Slack in terms of daily users. In combination, both tools are used by roughly 23 million users daily which is more than half the population of Canada. Tools such as Teams and Slack provide valuable support for geographically or temporally dispersed team members to collaborate on their work activities. Even for co-located teams, the persistent chat capability of such tools allows team members who were not present for a conversation to catch up when they return to the office. Both Teams and Slack can be accessed via web browsers and from their own smartphone apps.
The other article provides four tactics for helping team members avoid digital distraction. Creating quiet spaces for mental recharging, encouraging device-free breaks, facilitating the development of team working agreements which will include reasonable time and location boundaries for device usage and supporting team members who choose to block time in their working calendars for distraction-free work can all help.
Whereas the first article highlights the growing importance and incidence of being constantly connected, the second encourages us to help staff to disconnect.
What is ironic is that an agile mindset values focus and yet the tooling used to support agile delivery encourages greater levels of distraction.
But something critical is missing from the second article.
One of the most important influences for encouraging our team members to find a healthy balance is their perceptions of our own actions. When we are in one-on-one or group meetings, are we closing our laptop lids and keeping our phones in our pockets or purses and letting calls go to voicemail? Are we resisting the temptation to initiate or to respond to team conversations or questions outside of normal working hours? And are we self-aware enough to be aware when we don't model the healthy device usage behavior we'd like our team members to demonstrate?
Thou hypocrite, first cast out the beam out of thine own eye; and then shalt thou see clearly to cast out the mote out of thy brother's eye.
Social psychologist Heidi Grant's interesting TED Talk video providing advice on how to increase the odds of a positive outcome when we ask someone for help was published this week. Three of her four tips are to be specific about the help required and why it is needed, to not apologize for asking for help and to make the request live in person or over the phone.
While this advice can be applied to any situation, in a delivery scenario if team members are regularly demonstrating these steps it is evidence that they feel safe working with one another.
Being specific about a request forces a requestor to be more vulnerable. It's much easier to say "I could use a hand with my development work today" than to say "I really have no clue as to how to code this data interface to meet the performance criteria". It also puts the target helper in a greater position of vulnerability by requiring them to respond if they believe they have the necessary skills to help or not. Comfort with expressing vulnerability is a key attribute of psychological safety.
Helping someone is supposed to feel satisfying and should feel natural when we have a healthy working relationship. Canadian stereotypes about saying "sorry" aside, if someone apologizes to me when asking for my help, it makes me feel that they don't feel comfortable with our relationship. In a team with a higher level of psychological safety, team members are confident that they can count on one other.
Finally, if I don't feel comfortable asking someone for assistance and am pessimistic about the likelihood that they will help me out, sending the request via e-mail or leaving them a voice mail message is a safe way to avoid a potentially unpleasant interaction. On the other hand, if I feel that my colleague has my back, I'll have no concerns with speaking with them face-to-face or over the phone to ensure clarity of understanding and a timely response.
"Lean on me, when you're not strong