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
The perils of over proactivity
Categories: Project Management
At the start of our vacation, we had one stop en route to our final destination. We were supposed to have a two hour layover, but after landing we learned that our outbound flight would be delayed by another hour. As the end of that extra hour drew near we were informed that our flight would be delayed by a further two hours. While we were dismayed by these successive delays, I enquired and learned that the cause was a mechanical problem with the plane we were supposed to have departed on, hence the airline operations staff had to scramble to locate an alternate aircraft. While this was a frustrating situation, we appreciated the safety first focus of the airline and as we had built sufficient wiggle room into our travel plans we weren't overly concerned.
As we soon overheard, this was not the case for all of our fellow passengers who were waiting near the gate.
On our flight was a small tour group whose subsequent travel plans appeared to have much less buffer built into them. While the new departure time for our outbound flight would still fall within their critical path, their group leader was understandably concerned. Rather than addressing her concerns by speaking with the gate staff to understand the cause for the delays or by exploring options with them in case our flight was further delayed, she decided to take matters into her own hands.
She booked the group on a new flight with a different carrier to the final destination. As this was a last minute booking, the costs were quite high.
Our outbound flight pulled in to the gate on time based on the updated departure time. The group leader proceeded to argue with the airline's gate staff that they should refund her group for the costs of their alternate bookings. The airline staff were very professional but also quite firm in letting her know that the airline was in no way responsible for her actions and she should have consulted with them prior to taking such a step.
We may be accountable for an outcome but we shouldn't assume ownership for issues which belong to or can be better resolved by our team members or delivery partners. We have enough concerns which we personally own to take possession of other's albatrosses.
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
When I teach agile fundamentals classes, I frequently emphasize the importance of inspection and adaptation. Teams which don't use feedback loops with their products and their processes should not consider themselves to be very agile.
For those teams which use an iteration-based cadence for their delivery such as those who have implemented the Scrum framework there have multiple feedback loops to help them improve. A common example is comparing how many product backlog items they were able to successfully complete during an iteration with how many they had forecast that they would be able to complete at the beginning of the iteration.
For stable teams using fixed duration iterations, a reasonable assumption is that over time the volume of work which they can complete should become progressively more predictable which in turn should improve forecasting.
So what happens when a team consistently misses their iteration forecasts by a significant margin?
If it is a team which regularly completes more work than was forecast, this could be the result of traditional management oversight causing team members to act very cautiously when estimating their work. Letting the team know that it is normal that they might miss their iteration forecasts on occasion and spending effort on making the team feel safe might help them to start making more aggressive forecasts over time.
But what about the team who is frequently completing a lot less than they had forecast?
It would be very easy to write off such teams as undisciplined or immature but such judgments won't help the situation.
There could be many factors causing the team to fall short including:
A retrospective provides a safe place to identify the situation and to come up with improvement suggestions which the team can take into their next planning session.
This might also provide a good opportunity for the product owner to express some sadness that the team wasn't able to meet their forecast and to help them understand how this could reduce their credibility in the eyes of key stakeholders.
Regardless of the cause, understanding why the team is over-forecasting is an important step as that information can then be used to create a sense of urgency regarding this behavior.