The 8th agile principle

In my last blog post I wrote about the 12th Agile Principle. In this blog post I’d like to explore the 8th Agile Principle:

The most efficient and effective method of conveying information to and within a development team is face-to-face communication.

What is this principle about?

To explain what this principle is about, I’d like to share a short anecdote about a project I was working on all the way back in 1998. I know…long time ago.

The project was to design an online banking presence for a consumer bank. I was the project manager from the design agency and we were responsible for specifying the UI. Our deliverable to the client consisted of mockups of the screens created in photoshop and a ginormous GUI doc that explained how every element on the page was supposed behave. Once we were done with the GUI doc our engagement in the project was complete and we moved on to the next project. At least in theory.

Not surprisingly, once the documents landed on the desks of the development team, questions started popping up right and left. Before we could engage with the developers however, a new contract had to be drawn up covering “support”. This alone took at least a couple of weeks to make the various approvals and signature rounds. When it was finally approved our “support” consisted of at least 2 full days of meetings with us and the developers in a conference room, reading the document together page by page. No whiteboard sketching, no fast prototyping, no coding at all happened. Just reading a giant document together. I think you can see where this story is going.

Historical perspective

When this principle was written back in 2001, the norm for communicating to development teams was more like the story I shared above.

Development teams were most likely not cross-functional teams but separated probably physically and organizationally by discipline i.e. a separate QA team sitting in one building, a separate db team in another and so forth. I doubt very much that UX specialists would have even been considered to be part of the development team.

The authors of the Agile Manifesto and the 12 Principles were themselves, “sympathetic to the need for an alternative to documentation driven, heavyweight software development processes.” They were reacting to the fact that more emphasis was placed on getting the documents right instead of enabling and supporting the people responsible for building the software to talk to each other.

I think the emphasis on “face-to-face” communication in this principle is more about real-time communication and collaboration by whatever means, than it is on the actual physicality of being face to face.

Today’s context

Fast forward to today and the landscape is very different. If you happen to work in an agile company such as XING you’ll find cross-functional development teams working on the same product together in real-time. Some of these teams are physically located together. They have ample whiteboards to sketch and discuss ideas. The developers have large desks that comfortably fit 2 people sitting side-by-side to accommodate pair programming. The product owners and UX people are also part of the team, making it easy to get fast feedback and answers to questions.

Additionally, for our distributed teams, we have communication and collaboration tools such as HipChat, Slack, Conceptboard and advanced video conference systems, which simply did not yet exist in 2001.

8th Principle Anti-Patterns and tools for fixing them

Recently, my colleague Andrea and I conducted an Introduction to Agile workshop for all the recent hires at our office. We spent the beginning of the workshop explaining and exploring the agile manifesto, the 12 agile principles and the core agile values together.

We polled the participants about which of the 12 principles they felt was most in need of improvement in their current experience. More than one person, myself included, mentioned principle #8. Here are some of the anti-patterns that were mentioned in relation to this:

Anti-pattern: Using digital channels to communicate instead of talking

One person had observed developers who are sitting not more than 20 metres away from each other sending HipChat messages rather than getting up out of their seats and talking “face-to-face”.

I’m as guilty as the next person of this and can even confess to sending Whatsapp messages to my wife in the morning instead of getting off my butt and going into our room to talk to her.

In the work environment as well, I can imagine part of it is down to us being glued to our chairs, but I think there is more to explore first before accepting that laziness is the only source of this anti-pattern, or even that this should always be viewed as an anti-pattern.

In an open plan team space one of the highest commodities is the ability to be free from interruptions. Ambient noise in particular is hard to escape — from traffic noise in the street below our windows, to someone two desks away having a Skype chat with a colleague in a different office, to two people pairing talking through some code. When you’re trying to focus it’s often a choice between the noise-cancelling headphones or finding a quiet place in the rest of the office or terraza to get some peace.

I know for myself, when I see a developer on my team with the headphones on, the last thing I want to do is tap them on the shoulder for a face-to-face conversation. I prefer to send a HipChat message that they’ll get notified about later, or even an email. And if they’re sitting someplace in the office I usually opt for waiting for them to come back to the teamspace to talk.

So in this context I wouldn’t exactly call using digital channels over face-to-face communication an anti-pattern.

On the other hand, things start to smell when I see email threads nested with up to 5 replies to replies. My general rule regarding email threads is to limit threads to 3 replies and then have a conversation — whether it’s face-to-face or over Skype isn’t as important as just having that conversation.

I see the same tendency when one team creates a PR on another team’s repository. One antidote to any misunderstanding would be to have a conversation before-hand for developers to agree on what the team plans to do and how.

How to fix it

• Avoid overly long email threads and replace with real-time conversation. My rule of thumb is 3 replies limit.
• If there is something urgent you need — an answer, an approval, etc. and the person you need it from is looking available, ask them in person. If they aren’t looking available, send them a digital message, with a plan to follow-up in person.
• If you are working in an open-plan space and headphones are used to block out ambient noise, consider using some kind of visual flag on your workspace to let team mates know if they can disturb you or not. I printed and laminated a pretty mermaid picture for my team that they use to signal “do not disturb”.

• For cross-team communication especially it’s good to convene and agree at the outset on who will do what, and how to avoid any misunderstanding. Summarize the agreements in GitHub issues or JIRA tickets — whatever medium you agree on.
• With communication channels in general, it’s worth it to address this topic when the team is creating their working agreements. One colleague mentioned a team that was waiting 22 days for a pull request from another team, because they assumed that team was watching the JIRA ticket where the request was made. 
  Agree as a team on what type of information is used in which channel, for instance, chat, email, confluence, GitHub, etc. And be sure to revisit this topic frequently!

Anti-pattern: Not all the team is located in the same physical place

I will be the first to say that if I had a choice between working with a distributed team vs. a co-located team I would choose a co-located team. In my role as Agile Coach my radar for picking up on the temperature of the team is strongest when I am in actual physical proximity to the team. I can read their body language, hear side conversations/laughter/arguments, “feel” tension.

In our context here in Barcelona , distributed teams have always been a given. By intention, from the organization, our product owners are sitting in a different country. For sure this makes things extra-complicated. For example, I frequently find myself in switchboard mode — either telling our product owner that the developer he is trying to reach isn’t at his desk, or sharing with the PO the “temperature” of the team (see above).

Meetings can be fast and simple, or, if the internet connection is not so great, extremely frustrating and painful. There is more technical overhead of keeping communication flowing and making sure “remote” colleagues are optimally included in all team meetings.

The fact of the matter is though, that more and more companies, mine included, are using remote-friendly policies to both retain existing employees and attract new hires in the war for talent. As mentioned above, in our case distributed teams have always been our norm with our POs and sometimes UX based in Hamburg. We have a pretty relaxed policy towards working remotely in general, which is more or less, if the team is ok with it you can do it. In some cases, we now have teams that are completely distributed — with each team member (not just the PO) working from their home location.

How to fix it

• The easy answer would be to avoid it at all costs. By this I mean have one policy that applies to everyone on the team regardless of their role.
• The more accommodating solution would be to embrace remote work and provide technical support and behavioral guidance to make it work. As is often the case, unless you have worked remote, it is difficult to know what kinds of modifications are necessary to keep team communication flowing. I asked one my “remote” colleagues for his perspective on this and he said that an interesting thing happens when the balance of people working remotely outweighs the people sitting in the same physical location. Conversations and interactions become clearer and shorter. The team chatroom becomes the hub of communication with the added value of the chat history being saved to refer back to later. This is something you would miss actually with face to face communication unless the conversation was recorded.
• There is a quite thorough article I read about how to build a remote-first team culture. It covers the pros and cons of remote-first teamwork. I highly recommend it as a source of many more tips and tricks. It is called: Building Remote-First Teams.

Anti-pattern: Forgetting that a user story is a promise for a conversation

For some teams, especially where trust is low between the team and the product owner, I have sometimes encountered this anti-pattern. Usually it develops in the aftermath of working on a user story that was particularly painful to finish. Symptoms include: unclear or incomplete requirements where developers think the story is done but the product owner rejects the story as not delivering what they asked for. Or it could be that requirements kept changing over the course of the sprint.

In either case I have seen teams react to these situations by insisting that all the requirements are explicitly listed in the user story to such an extent that the story looks more like old school requirements documentation.

How to fix it

• Help the whole team to agree on and be comfortable with a definition of ready that provides enough information at least to get started. I sometimes suggest that the DoR should at a minimum include a description of the “happy path” scenarios the PO wants. The idea behind this is to encourage face-to-face conversation before work starts and ensure that more conversations happen DURING the sprint.
• Use grooming sessions to have the essential conversations between the PO and team to clarify expectations of what the user story is about.
• Encourage the team to show work in progress to the PO and ux specialist to tease out any “hidden” requirements that may have been overlooked.
• One way to “force” the conversations to happen that I’ve tried with success is to have the PO, QA, and developer write acceptance tests together once the story is planned into a sprint and before any code is written.

There are, of course, other techniques to add to your coaching toolkit that will help you create an environment and cultivate a mindset of conversation and collaboration.

Some thoughts on the meaning of conversation

The final thought I’d like to share about this principle is to remember that it’s conversation we’re trying to encourage here. And conversation includes both talking and listening. It’s asking questions, debating, agreeing, and disagreeing. Most of all it’s the energy that is created from human to human interaction. And for me that’s what this principle is all about.