Anonymity vs. Agile maturity... (vs?)

What makes a grown up team? Tough question! Think about it. It’s already pretty hard to measure maturity on people, even tougher would be to do it on groups of people, wouldn’t it? Well, not really. There are several indicators that can help answering such question, and though most of them rely on subjectiveness, they can show us more or less the level of maturity an agile team has.

The concept of Agile Maturity has been questioned on the last few years by both authors and tool developers, but bear with me on this subject just for the sake of understanding this controversy I'm raising and want to debate upon. When attending the concept of Agile Maturity or, say, the level of agile-ness a team has achieved, most authors (i.e. Balbes, Wolpers) rely on one, a few, or all the following aspects:

• Delivery - Regarding sustainable pace, value, simplicity, frequency and technical excellence.
• Organization - Collaboration, communication, self-organization.
• Change - Adaptation, continuous improvement, metrics.

And that’s ok. That covers pretty much everything we need to be acknowledged as a mature agile team by the book. And we can find plenty of documentation on this (like this one). Nevertheless, I want to raise another aspect, which I think is the cornerstone of any mature organization, and even takes more importance when we aim to become a grown up agile team. I'm talking about Trust.

Trust me. I'm famous.

To be fair, some authors have dug into this previously. However, their insights were more on the client <-> dev team relationship. Does the client really trust the developers are doing their job? Do they really understand this is not just a 5-minute task but a complex 5-points-1-week-2-devs job? Or are they just playing along while waiting for the meet to end  to browse for faster less lazy companies?

Anyway, the trust I’m talking about is the one we get within the team, and that’s not something you can easily find online.

So, let’s paint a pretty common scenario: Sprint retrospective. 3 years old team. Dealing with the sprint to sprint issues and glitches. Stakes are high. Holidays seasons approaching. Time to talk about the ups and downs of the previous 2 weeks. It’s actually the downs that worries you. Apparently acceptance testing is lagging behind. The PO has been kind of absent for a couple of weeks. Who’s to say what’s on his mind but it’s really getting out of hand. PRs start to stack up. Board is getting messy. Someone has to say something.

You crack your knuckles ready to fill a concise but extensive virtual post-it describing the situation, assessing the problem and proposing a couple of solutions. But seconds before starting the facilitator drops an A-bomb on you. “We’re having troubles with the app we’re using for retrospectives and we’re doing it live this time. So let’s write down our insights on Trello cards instead…” BOOM! No anonymity this time. Your temperature raises. Your pulse paces up. You start hoping that anyone else will raise the issue. Maybe leaving it for the next meeting is not that bad. For some reason, you won’t take a stand and highlight a problem if it’s not an anonymous call. Even when it’s constructive criticism, the problem is definitely real, and talking about it will help the team to deal with this right here and now, you won't do it. Now, what’s keeping you from talking openly? Is it just you or other team members feel the same? Why is anonymity so important? Is the need for anonymity a sign that your team might not be as mature as you thought it was? Is there a middle ground we can start with?

Amateur fright

First things first, for focus' sake, let’s discard the stage fright as a variable. We’ll assume no one is afraid to speak in public, since this is actually the most common problem arising on teams, specially on newcomers or larger crowds. I remember a few months ago I went on a conference and they had to rearrange the logistic of the presentations to include people who were afraid of presenting their lectures in front of hundreds of attendants (Later they felt perfectly comfortable talking in front of 50 people when actually delivering the talk in question, apparently the size of the crowd matters). So, we’re not talking about that here.

Having said so, it is inevitable that our first attention would go to the newbies. The ones who are just starting, or have started later on the project, are the ones who crave for anonymity the most. And it’s pretty obvious. It’s understandable. Take as an example meeting for the first time with the family of your significant autre. You wouldn’t come up to your future in-laws and say, “well, actually that pasta was way under cooked”, would you?. Well, trust and confidence are evolving feelings, they're something you earn, and though you should feel entitled to speak up, being prudent is wiser, common sense is a must, respect is mandatory. Always think of wrapping everything in a positive constructive way. You CAN say anything but you SHOULDN'T say it in any way you want. Most of the times it helps to say it a few times in your head before actually speaking up, mostly when you're dealing with negative or conflicting issues. (In fact, if you want to dig even deeper on the challenges in store for newcomers to agile ceremonies, take a look at this post about surviving retrospectives as a beginner, or this one about an interesting solution for a subtle ramp up).

So, what to do in this case? On my early days I've found helpful to have a proxy. There’s always someone closer to you who can raise the question instead, but, and this is important, you should remain as the original enquirer. This means you shouldn’t delegate your protagonism, but just the introduction. Your coworker could say something like: “..well, we were discussing velocity with Lalo (that is me. Hi! I’m Lalo) and he has some interesting insights on this subject…”
This approach presents several advantages. It gives you implicit support, it states that this was something thought through, not just a spur of the moment; and you remain the inquisitor. It gives you entity.

I'm not worthy! I'm not worthy!

Something similar happens with seniority fright. I've always said that one thing is speaking in front of relatively same seniority devs, another pretty different thing would be facing a retrospective with Rebecca Wirfs-Brock, Linus Torvalds, Kent Beck and John Carmack.

What we can do as a team on this case is remembering the always useful, though most of the times forgotten Prime Directive.

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”

This provides a layer of confidence and trust, as things spoken are stronger than implicit ones. We get reassurance, support, and the confirmation that we’re all on the same boat and warning that there’s a hole on the deck is not to blame the one who dropped the screwdriver, but a proposition of thinking together ways to prevent that to happen again.

But it seems we’ve not yet dealt with the topic for this post, which is anonymity. Well, we kind of did. A confident member is not afraid to speak up. A member who understands which is the true goal of their insights and commentaries, and knows for sure the rest of the team feels the same, is less (And pay attention here, I used “less” instead of “no”) compelled to look for anonymity. And as strong self-confident encouraged people make strong self-confident encouraged teams, there’s our target.

The long and winding road

Building confidence is a long term goal. It requires a few iterations through trial and error, and of course low to nonexistent rotation (though trained devs usually maintain their level of trust and self confidence throughout their teams). However, the results are substantially better, and most of the team would thrive when having members who share this vision, who aren’t afraid to speak up.

Anyway, there are a lot of companies that can’t afford, either for economic or time related reasons, to put this amount of time and effort into this task. So, sneaky companies have come up with shortcuts.

There are a number of apps which provide anonymity and are very easy and safe to use. There are even team methodologies and dynamics developed to provide anonymity on agile ceremonies.

However, this is a double edge sword.

We’re assessing the symptoms while not curing the disease at all.

These could be useful as provisional tools, but we should definitely keep in mind that this is not the solution, and in the long run we should investigate for ways to build up team members self confidence if we're aiming for a full grown up agility.

There is another caveat. Anonymous opinions are always always ALWAYS partial, because there’s no room for extensive and objective debate. I remember a while ago our company got a low rating from some of the members on a retrospective. The topic was “Human quality“. Anonymous really low rating. We stared at each other in disbelief. What was the exact reason for this rate, given it was such a broad subject? What had happened? Was somebody offended by someone? Was it just a matter of environment neglect? Was a misconception?

No way of knowing. Because we couldn’t debate, and we couldn’t work on solutions for something we didn’t know what it was.

So, sometimes anonymity not only shows agile immaturity, but even gets in the way of arriving to such state.

Confidentiality is a middle ground. Even though somebody will know, it won’t be as strong as if everybody knew. If we could go up to someone we really trust and talk about a particular issue, they can be our proxies and we could delegate the responsibility of facing the rest of the team. In case of needing more insight, the issue could be later discussed between those two people who would have a bigger picture and come up with a better understanding on how that topic was taken in the team.

Again, this should be a temporary measure.

Creativity helps!

Have you ever felt fed up with routine? In simple everyday tasks like, say, commuting or having lunch at the same deli over and over again for a thousand days? Did you notice in those occasions it gets harder to engage in conversation? It gets so painful to interact with others? Routine and repetitive tasks tend to put us down. We get fed up. We get bored. We fold on ourselves and communicating gets more like a job. Anonymity helps there. It's easier. We implicitly and subconsciously tend to crave detaching away from those situations. And this feeling pollutes our opinions so much we fear it will translate in a negative way. So we end up in fear everybody finds out about it.

It takes work to solve or avoid this since there are usually a couple of ceremonies to look for in agile. From dailies to retrospectives, to 1on1s and demos.  It's a chain reaction, really. Periodic meetings with exactly the same structure eventually get boring, people get frustrated, their opinions suffer, people acknowledge this and fear that others might notice, anonymity cravings strike.

The solution, I mean, the answer is really obvious and simple. They way to implement it, on the other hand…

Again, no immediate solution. Diversity and creativity takes commitment. There are a lot of resources online, a lot of methodologies, mountains of information and research done. You just got to find the perfect one for your team and, believe me, there are tons of exercises and approaches to different ceremonies (i.e. check this post on dailies).

People are always afraid of change. But once you get going, you will find you feel excited and eager to share your insights on the next ceremony. And you'll soon get to the point that what you're really scared of is changing to a no changing state.

Summing up

Anonymity has no place in full Agile maturity, though the path to it will be long and it will require work on every member of the team. Respect on others opinions, humbleness, self confidence, trust and courage will be mandatory. But we should keep in mind that it pays well off. And it lasts. Your opinions and insights matter, and as they are your opinions they should come from you. As a member of an agile team you should be proud of them and the changes they promote or the debates they raise. Don't hide and don't be ashamed of what you think. We're all on the same boat, and that idea you're hiding behind a curtain of anonymity might be the one which, after some development or fine tuning, leads the boat to the shore. People who have worked in such environments remain that way all the way, understanding that a confident proud developer is the true cornerstone of a confident proud mature agile team.