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.
Harvard Business Review published an article this week covering six causes of burnout and how we can reduce these. Let's consider these through the lens of agility.
Having an excessive workload over a prolonged period of time is one of the most common causes of burnout. The eighth principle of the Manifesto argues against this: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." People laugh when I say in my classes that we need to strive for no weekend or overtime work, but downtime is critical to maintaining a sustained pace. This requires a shift in thinking for leaders to prioritize delivering value over just keeping people busy.
A perceived lack of control over our work is another cause of burnout. Agile teams are expected to be empowered by their leaders to identify their ways of working rather than having those dictated or prescribed. Team members define and pull their work rather than have it assigned to them. This autonomy means that they can be creative at handling challenging or overwhelming situations.
A lack of extrinsic and intrinsic rewards was also listed by the author as a contributing factor. While the magnitude of external rewards will be subject to economic constraints, informal recognition is usually more frequent through the product (e.g. sprint review) and process (e.g. retrospective) feedback loops that we expect with most agile approaches.
Having strong support from one's immediate work community is a good hedge against burnout. As I wrote in my last article, members of teams which are at a high-level of psychological safety draw comfort from knowing they have someone to lean on when they need a hand. A greater level of team awareness means that their team members are also likely to pick up on subtle cues of excessive stress.
The article includes a lack of fairness as another cause of burnout. While individual contribution is still recognized, the granularity for declaring success is at the team level. Agile transformations must include a review of performance review and formal recognition programs to ensure that team work is encouraged and that rewards are not divisive.
Finally, a disconnect in the values of the individual and the leadership of their company can also lead to burnout if team members face the internal struggle of staying true to what they consider important. Agile may not be a cure for misalignment with company values but within the safety of a team, each individual has a voice to contribute to the values and culture of that team making it a safe haven from the storms outside.
For many, agile is about delivering value quicker or with increased quality, but true agility is also about putting people first.
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.
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.