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
Old sayings might not be the first thing which comes to mind when considering agility, there are many proverbs which are apropos.
Two heads are better than one (or the similar Maasai proverb "One head cannot hold all wisdom."): I've found this saying to be useful when presenting pair programming. Prefacing an introduction of the practice with this saying helps as people will generally agree with its merits so they are more likely to be receptive to the concept of non solo work.
Out of sight, out of mind: This proverb can be used when referencing traditional techniques for tracking and reporting delivery progress and contrasting those with the increased transparency which is encouraged with agile approaches. Most listeners will remember a time when a lack of visibility or shared understanding resulted in needless churn from one or more key stakeholders.
The wise do as much as they should, not as much as they can: Whereas traditional approaches might have encouraged gold-plating or feature bloat, this saying is well aligned with the tenth principle from the Manifesto: Simplicity--the art of maximizing the amount of work not done--is essential.
A stitch in time saves nine: Cost of poor quality increases when we don't take the time to identify the root causes for variations and merely inspect and correct. Shifting quality "left", reflecting on how we can improve our processes and then implementing improvement ideas quickly and developing quality-focused Definition of Done guidelines are all ways in which this saying is put to good use.
Cut your coat according to your cloth: Focus, like transparency is a pillar of Scrum and most other agile methods. Multitasking, building up too much work in progress or taking on more work items that we can complete in a quality manner are just a few examples of how we ignore the wisdom of this proverb.
Chickens should be seen and not heard: While we encourage stakeholders to visit and observe ceremonies such as standups or sprint planning, their purpose in attending is to learn and not to disrupt.
When we were younger, whether it was from our parents or our grandparents, chances are we heard a number of proverbs. While those might have been intended to impart wisdom to us during our formative years, they can also be relevant in our adult lives.
I am occasionally asked by learners in my project management fundamental classes which is the most important knowledge area in the PMBOK® framework. My usual response is to say that each knowledge area is important but the emphasis and level of effort spent on each will be vary depending on the specific context of a given project.
But if I was forced to choose one PMBOK® knowledge area to recognize over all others, it is Project Stakeholder Management.
This choice might surprise some of my readers, especially given how much I've written about Project Risk Management. After all, Project Stakeholder Management is the newest knowledge area, and is covered in fewer pages in the PMBOK® Guide than the others. The triple constraint doesn't include stakeholders so why would I emphasize it more than scope, schedule or cost management?
One reason for this is that knowing who your key stakeholders are as well as understanding their attitudes towards and influence over your project are key inputs into many of the processes from all of the other knowledge areas. This is why Identify Stakeholders is one of only two processes in the Initiating Process Group.
If you have been involved with project work for a while, you will have been part of or at least heard from teams who ended up coming in over budget, behind schedule or delivering less than was approved, but as a result of effective stakeholder management, the project was still deemed a success. You might have experienced the opposite with a project which was completed on time, within budget, and with scope delivered within quality specifications, but the dissatisfaction of a key stakeholder resulted in everyone feeling the project had tanked.
One of the reasons that many of us entered the project management profession was that we wanted to continue to develop our skills. While we can get better at scheduling, budgeting or any other hard skills, there is much greater potential for long term learning by focusing on soft skills. Honing the multiple competencies required to manage stakeholders provides us with a career long development road map and the returns on this investment are likely to be much greater than with hard skills.
Advances in machine learning and artificial intelligence will negatively impact many current jobs. I don't worry too much about the project management profession. So long as project work is done by and for human beings, the need for effective stakeholder management will continue to be a hedge against automation-driven job losses.
They may forget what you said — but they will never forget how you made them feel - Carl W. Buehner
While teaching a class earlier this week, a learner asked how will team members start to feel psychologically safe, especially if they are working in a company whose culture isn't fully supportive of this critical ingredient to a high performing team.
Updating existing corporate values, and senior and middle management leaders holding themselves and each other accountable to modeling behaviors consistent with these refreshed values helps as does coaching at all levels of the organization. For individual team members, the Scrum values can provide good reminders of our own responsibilities for creating a psychologically safe working environment regardless of which delivery framework or method we are using.
Commitment: While we normally think of this value in terms of committing to achieving team goals, this value can also be considered as a shared commitment to creating a safe environment.
Courage: The Scrum Guide encourages team members to show the courage to do the right thing and work on tough problems. This is equally applicable to interpersonal relations. It takes significant courage to speak up when you witness behavior which is corrosive to psychological safety especially when the person misbehaving is more senior than you are.
Focus: While team members should be focused on completing work, living this value also means that we are focused and actively listening when we are part of a discussion or ceremony. By doing that, we are better able to pick up on the tone and body language of others to understand if they are feeling uncomfortable about what has just been said or look like they want to say something but just need that little bit of encouragement to speak up.
Openness: Just as we expect our teams to be transparent about the blockers they are facing, the same level of openness should be exhibited during retrospectives or other opportunities for inspection and adaptation with regards to how we interacted with one another.
Respect: Demonstrating this value towards our team members means not only treating them with respect but challenging others who would show them disrespect.
Edmund Burke - "The only thing necessary for the triumph of evil is for good men to do nothing.”