Easy in theory, difficult in practice

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.

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.

It is easy to say that demonstrating behaviors consistent with the values and principles of the Manifesto is proof of agility but this test leaves significant wiggle room for interpretation and for exception cases which fall through the cracks of the four values and twelve principles.

It is also somewhat of a cop-out to plagiarize Justice Potter Stewart's famous phrase "I shall not today attempt further to define the kinds of behaviors, practices or methods I understand to be embraced within that shorthand description ["agile"], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the team involved in this case is not that." This method opens the door to framework fanaticism and furthering the conceit of "there's only one right way to be agile".

Here are three questions you might consider asking:

1. Is the team improving across the three dimensions of delivering business value early & frequently, improving product quality and making people awesome (as per Modern Agile)? A team might be capable of improving their performance along one or even two out of the three dimensions, but this often comes at the cost of the third. One could consider these three dimensions to be an agile equivalent of the project management iron triangle.
2. Are regular feedback loops well established for both the product itself and delivery process and do these loops result in changes to the "what" and the "how"? Whether these loops follow a fixed cadence (e.g. reviews & retrospectives tied to the the heartbeat of a sprint) or are performed on a just-in-time basis when a continuous flow delivery approach is utilized, they demonstrate that the team possesses the humility and understanding that there will always been the need to inspect and adapt.
3. Is there evidence of the team truly self-organizing when it comes to how their work is done as well as how they interact within the team and with key stakeholders? Key characteristics such as courage, respect and collaboration should be evident.

Agility should never be treated as "the" goal but rather as a catalyst towards achieving one or more business goals. But defining what it means to "be" agile in terms of the outcomes we want to realize can help us understand whether we are making a difference or not.

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.