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 Last Samurai (Wiki Quote Org.)]

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.

Why developers don’t use a Version Control System (CVS, SVN, Git, Hg, ...)?


Tale #1: The stolen code

Jack woke up early that morning, he goes to the kitchen and found it in a total mess. All things on the floor; his clothes and documents too; by that moment he already understand what happens, his house was robbed!

Among others things, he quickly notice that his laptop was missing too. And here comes the real problem, on the HD he had the sources of various application he owned; applications already sold and with maintenance contracts. He did not made a backup somewhere else.

After that incident he de-compiled an old version of the application. He also needed to update / rewrite some modules because they were not working as the production version. Also the decompiler output some code as assembler code.

By the same week he start using a Version Control System, with a web provider.

• Time working without version control system: ~3 years
• Time working with version control system, after a big loss: almost immediately

Tale #2: Corporate resistance vs. personal acceptance

Peter had worked as developer for almost  8 years, he has never used a Version Control System. At his actual Job a project was conceive to adopt a version control system. All developers were trained, all software was installed and a new corporate policy was created to enforce its use.

A year and a half after project completion, Peter still did not use the Version Control System, he just made the code changes and upon requests he upload the final version of every requirement to a branch. He also find himself with a bunch of conflicts because he worked on a very old code base and never gets the new one.

Recently he started a personal project, some software product he believe will be very popular and generate some sales. He start working with the same methodology: manual backups, total application rewrite because of code lost, inability to revert to a stable version after a big re-factor, among other bad practices. By the second week of work he, voluntarily, starts using Git.

• Time working without version control system, on formal jobs: ~8 years
• Time working without version control system, on personal projects: 2 weeks

Tale #3: Software vendor resistance

Company A (the Client), hires Company B (Software Vendor); to implement a new system. The relation include a full development effort of the vendor; and a mentoring period to local (at A), resources to gain experience on the new system and continue its maintenance labor. 

After months of work, on his facilities, the vendor finished the work and the user acceptance tests (UATs) began. At this point the problems start to arise. Every time a bug or problem was reported and the vendor starts working on it; another functionality gets damaged. When the root problem was tracked a guilty was identified: the vendor was not using any versioning tool; so they just get the last “stable” sources from disk and start changing it. After they finished their work they fix the reported bug; but introduce a new problem on another functionality. This can be addressed with  a good set of automated tests, but you still will have the problem of code lost over time: they can’t just rollback to a known stable version.

The Moral 

A bad behavior without consequences, is repeated.

The problem with our first case, is that he never felt the necessity to use a tool to control software versions until he suffer a source lost because of a house rob. His bad practice never gets punished.

Our second case, has the same root problem. On his past jobs he was never forced to use a versioning tool. So he just does not care about it. But, wait on his actual job exists a policy to use a tool. So why he does not use it? because the policy does not include any admonition to be applied when people do not follow the rules.

The third and last case is more of the same. The client company does not include on the service contract a section of regulations or procedures to be followed by the contractor. If the contractual obligation had existed along with a set of repercussions for the software vendor, the later will not be incurring on the flaws described.

For latecomers into the versioning tools usage

If forever reason you are new to versioning tools, here you have a short list of tools including the most popular, they all are free:

• Git, read the documentation section
• Mercurial (hg), read the guide section
• Subversion (SVN), read the SVN Book

Agile Maturity Model [Level] Survey

Please take a moment to fill this short survey, when done you can share it with other people using or planning to use Agile methodologies.

Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.