Showing posts with label scrum-master. Show all posts
Showing posts with label scrum-master. Show all posts

Sunday, September 9, 2012

Bad Communication Habits (2 / 3)

2. Inverted channels priorities

Background

I've seen many teammates taking to each other using an inverted priority for the following channels:
  • Phone
  • [Direct] Conversation
  • Emails or other text-based channels
Any time a person is involved within a negotiation (requirements, specifications, bugs reports, ...); that person will prefer to talk all others involved with the most formal channel in order to protect herself and document all agreements.

So they, try to send all details first in a written form (email or similar); if that does not help they try with a phone call, usually a conference call for others to listen and be witnesses. Finally, if that does not help; they try with a direct conversation or meeting.
image/svg+xml email phone conversation

This approach is not effective for two things
  1. The main focus, the intention behind, is to cover all possible future problems resulting from misunderstandings. The intention is to have (collect), evidences for future blame.
  2. We always get better results, in terms of time and quality, with personal interactions than with any other communication channel.

Managing this problem

To manage this problem, we can use some practices:
  • Always honor your promises: if you talk, face to face, with anyone and agree upon something; but later you do not honor your word that person won't trust you in the future. This situation will lead your teammates to collect evidences any time they need your help with something; so they can blame your later when you fail.
  • Prefer, always, the inverse order (conversation, phone, email): if possible try to start any interaction first in person; then by phone and using emails if no other channels were available. If you constantly do this your teammates will start to change their style (at least when interacting with you). Remember to observe the first practice.
  • Structure your interactions: if you start requesting to everybody that they should meet with you personally, some people can argue that you are just too far away and that they prefer to call or email you. Also, they can argue that this approach consumes too much time. The answer to these reactions is to schedule your interactions. If you constantly receive request for changes, manage to have a meeting every X day of your release cycle.

If you can follow these 3 practices, you'll have better agreements; you'll increase the confidence of your teammates (about you); and finally, you'll invest less time in interactions that do not lead to an easy understanding.

Wednesday, October 12, 2011

Bad Communication Habits (1 / 3)

1. "To many mind"

-Nobutada: Please forgive, too many mind.
-Nathan Algren: Too many mind?
-Nobutada: Hai. Mind the sword, mind the people watch, mind the enemy, too many mind... [pause] No mind.

The problem
Communication channels of software teams often starts to wildly swell, because of a poor management. This situation can throw down the cliff any development effort (in-house or product), because of the messy environment generated by it. The problem begins when every team member is able to talk with others inside and outside the team. This means that any stakeholder can talk to any team member and vice versa. You quickly end up with a situation like this (in terms of the amount of communication channels):
Unmanaged communication channels


The solution
You need to find a hub in every group. This is not a difficult task, if you look at Scrum role's definitions  you'll find that such hubs already were designed for us: they are the Scrum Master and the Product Owner. So, instead of having 28 communication channels (7 x 4), you end up with just one! 
Managed communication channels


Why does it happens?
Often in in-house development environments, and some not matured product companies, teams start working without a proper role definition. They instinctively know that each group have a leader but as time passed and problems starts to rise, roles and leadership vanished. Communication gets groggy because of everyone is talking at the same time to each other.

Users starts reporting the same issue twice or more. Two or more developers start working on the same bug without knowing it. No one has the “big picture” of the product / project, because everyone has a little piece of it.

Zooming in ...
To better illustrate the problem, we can inspect the following example: Imagine you are working on a Scrum team composed of 8 people. Your team needs to interact with three others: the Key stakeholders, and two production support teams (A and B); they have 4, 3, and 4 members respectively.

What will happen if all this people starts talking without a proper management? You end up with the following communication channels (from one group to another and withing each one):


Here is a graph to better explain the situation.


And, what about channels withing a group (Scrum team to Scrum team)?
We can not force people not to talk, and even if we could it's a very unhealthy thing to do. As you can see just between Scrum Team's members you could have up to 56 channels. These channels can create information islands. Again we have the answer on our face: Scrum Ceremonies (specially the daily Scrum). Those meetings allow knowledge sharing and avoid isolation and sub-groups.

One problem, when adopting Agile is that people thinks that is just another set of rules to follow and don't think about why the methodology suggest does kind of guidelines. Maybe if we show first the problems and then present the proposed solution they will be more willing to adopt the change.




Subscribe to our mailing list

* indicates required
Email Format