Silence and shortcomings

People will fail too

In agile, we acknowledge that mistakes and misunderstandings are going to happen, so we progress in small chunks and introduce safety constructions to fall back upon when things go wrong. Throughout the team we assume total transparency and constant feedback between individuals to be able to direct efforts in the right directions at all times.

Everyone is invited to share progress and setbacks as they occur. As all participants are jointly responsible for (and driven by) making the project a success, impediments must be brought to the surface as soon as possible so that we can act upon it.

But what happens when it becomes personal and the impediment is you? I found myself in this situation some time ago.

The ”Silence is the sound of risk piling up” quote is from Kent Beck's ”Extreme Programming Explained”. It basically means that elaboration and problem-solving should be performed by more than one person at a time, and that if a team room is not filled with chatter, the members are either trying to solve problems on their own or not solving problems at all. A silent team room is then a sure sign of problems (aka. ”risk”) being handled by individual developers, not communicated properly.

At the point of this tweet we had been regularly pair-programming on almost everything for a long time, but for some reason I hogged a story where I was supposed to be "The Expert". It became personal right at the sprint planning and as the days went by, I remember how ”my” story just kept hanging on the board. In stand-ups, I would line up a few task-sized notes on what went down, reassuring everybody that there were some unforeseen stuff in the way but that everything is going to be resolved, given that I got to work on in undisturbed for a few more days. But in reality, no substantial progress was being made.

As more days passed by the team started to be suspicious and finally they convinced me to allow them to help. With fresh eyes we established that the problem could be scoped down and we could soon show working software for the team and the customer.

Why was it so hard for me to ask for help? It was human weakness of course. Because if I told them the truth then, they would find out that I had not been honest before. It would be obvious that I wanted to look awesome in the first place!

As much as I would like to think that this would never happen again, I'm almost sure it will.

We, as agile practitioners, need to understand that members of our team, from time to time, will find themselves in trouble that they will find very hard to admit due to perceived personal shortcomings. They need to be offered a safe way out of this situation without having to loose face. This is how we rebuild trust within the team.

Trust is imperative for honesty, and honesty is what makes agile work. Watch out for the signs of fellow team members not feeling trustworthy anymore and save them from of a downward spiral of non-transparency and bad conscience.