Posts Tagged With: team building

Show respect!

I’ve previously written about the importance of courage and discipline for agile teams, so let’s review another important quality – respect. The Oxford English Dictionary provides two definitions for which are apropos:

  • A feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements.
  • Due regard for the feelings, wishes, or rights of others.

You might think that showing an appropriate level of respect is table stakes for anyone in any role regardless of their being an individual contributor or part of a team. That is true, but there are many dimensions to respect which need to be considered. Here are just five which I expect to see in practice in mature teams along with a few examples of how we fall short with each.

Respect for the organization’s resources

Producing excessive or unnecessary documentation, inviting people to meetings who don’t need to be there or not running disciplined meetings, and not regularly inspecting and adapting ceremonies or other delivery practices are just a few ways in which we needlessly squander the limited financial resources of our organizations.

Respect for our customer

Publishing out-of-date or inaccurate content in information radiators, failing to engage our customer in key ceremonies or the product decisions which they should have been involved in, avoiding the escalation of key blockers which our customers could have resolved or releasing low quality products just to hit a deadline are all examples of disrespect for these critical stakeholders.

Respect for our product

Skipping quality assurance procedures because we don’t have time, ignoring our Definition of Done just to say we completed our sprint backlogs, kicking low severity defects down the backlog, ignoring technical debt and regular refactoring show that we don’t really respect what we are producing.

Respect for each other

Making sprint commitments without full team participation, gold plating, showing up late for ceremonies, listening to make our point rather than actively listening, multitasking when we should be focused on what someone is saying, hoarding knowledge, not offering to help a team member when we are ahead on our work, and not having the courage to raise impediments which affect the entire team during daily standups or retrospectives demonstrate that we are putting our agendas and egos ahead of team success.

Respect for ourselves

Blindly following poor decisions without challenging them, making a sprint commitment which we know we can’t achieve, refusing to ask for help when it would result in more efficient, higher quality outcomes and failing to invest in ourselves (e.g. personal development, sleep, exercise) are common ways in which we make it difficult to look at ourselves in the mirror.

Confucius said it right: Without feelings of respect, what is there to distinguish men from beasts?

Advertisements
Categories: Agile, Project Management | Tags: , , | Leave a comment

Within sight, in front of mind!

The sixth principle of the Manifesto for Agile Software Development is “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation“. We have all experienced situations in which our not seeing the person we were speaking with resulted in a misinterpretation of what was being said. When teams are composed of dispersed members who don’t have the benefit of seeing one another face-to-face it takes longer for them to trust one another. It also can increase the volume of documentation required to create shared understanding.

It should be fairly simple for teams working for a single company on small, low complexity projects to be co-located, but as project complexity, scale or the number of distinct delivery partners grows, multiple constraints including the availability of skilled contributors, financial restrictions or real estate limitations might prevent team members from working in close proximity.

It is always a good idea for leaders to organize early and regular face-to-face opportunities to build trust within the distributed teams they are supporting.

But is that enough?

Augmented or virtual reality technologies have still not evolved to a point where we can accurately simulate being co-located, but using dedicated video conferencing facilities or even the webcams on our laptops can boost communication effectiveness.

Such tools can provide us with benefits such as:

  • Determining how engaged individuals are in the discussion. This can be especially helpful in ceremonies such as daily standups where it might be tempting for someone to tune out after they have shared their information. With everyone observing what each other is doing, the social pressure of not wanting to be singled out for multitasking might be enough to keep people’s focus on what is being said.
  • When supporting a small distributed team, a facilitator might forget to call on silent team members. Seeing their faces makes it easier for the facilitator to draw them into the conversation, especially if the facilitator is picking up on a facial cue that a team member is concerned about the topic but seems to be unwilling to voice their concerns.
  • Enabling richer participation in voting, brainstorming, team building or creative activities. For example, if a decision needs to be made, a leader can ask for a show of hands, and determine how eager individual team members appear to be based on how quickly they raised their hands.
  • Helping team members to better support one another. It is very challenging to determine how someone feels if they are just communicating with us via e-mail, instant message or phone call. Visual cues can help you see that they are having a bad day.

Albert Mehrabian’s 7%, 38% and 55% rule about the relative impact which verbal, tone and body language cues have on how much we like someone is frequently misstated as representing the impact of all communications. But we should never forget that old saying: “Out of sight, out of mind”.

 

Categories: Agile, Project Management | Tags: , , | 1 Comment

Does knowledge transfer change with agile?

We have all experienced this: a key contributor announces their departure and a mad scramble ensues to transition their knowledge to the rest of the team.

But does this change when the team is using an agile lifecycle?

On the surface, it might appear that there wouldn’t be any significant differences in how it is done regardless of the nature of the work or how it is performed. After all, knowledge transfer is usually a case of a subject matter expert educating others through either a live session or through some sort of persistent record such as a wiki, a video or an audio recording.

While this is true, there are characteristics and specific practices in agile delivery which can impact knowledge transfer.

Traditional delivery usually relies on individual specialists who remain focused on their role and area of expertise. On the other hand, agile delivery encourages the development of generalizing specialists who will develop a broader set of skills and knowledge. Higher levels of collaboration are also expected in such contexts which increases the amount of exposure that individual team members have to each other’s knowledge.

While this won’t translate into full fungibility across a team, there is less likelihood of only one team member possessing critical information. This won’t happen over night. It will take many weeks of working together as well as explicit encouragement by supporting stakeholders such as functional managers for generalizing specialists to develop.

Another enabler is non-solo work – pair programming, hackathons, mob programming and model storming are all practices using this principle. While the primary purpose of these practices is not knowledge transfer but rather quality and speed, it is a valuable side benefit. Rather than having experts share knowledge in an academic manner, demonstrating how their knowledge can be applied towards completing work items is more effective.

Whereas traditional delivery tended to emphasize documentation as the medium for passing work between roles, agile approaches focus on minimal sufficiency. While a newly formed team might require more documentation to facilitate shared understanding, a long lived team might successfully deliver with much less. The challenge becomes when a new or junior team member joins as there may be insufficient reference material to enable self-learning. But this should not cause any major issues if someone on the team volunteers to pair up with the newcomer to help fill in the blanks.

While the need for shared knowledge is there in all contexts, effective agile delivery can reduce the critical of explicit knowledge transfer.

 

 

 

 

Categories: Agile, Project Management | Tags: , , | 1 Comment

Create a free website or blog at WordPress.com.

%d bloggers like this: