Agile Collaboration in Developer Daily Life

The first part of this article series The Path to Agile Development was intended to convey a sense that SCRUM is only one of the many tips of the iceberg of agile methodologies, and the underlying significance requires a much more complex perspective. Building on this, this article primarily deals with the question of what agile working means for daily collaboration, especially for internal and external communication.
Communication in the Team

In times of work-life balance, home office, remote work, and flexible working hours, a very important aspect of agile work is often lost: communication. Its importance is unfortunately underestimated nowadays, and various problems can be traced back to insufficient or even lacking communication. While one could write a dedicated series of articles solely on communication techniques, errors, and feedback conversations, etc., I want to focus on the importance of (good) communication in this one.

Why is communication so important? In relation to the working world, many will probably be happy to have a colleague, maybe even two or a whole team. We humans are most efficient when we share work. That’s why companies usually consist of more than just one person. However, a group of people sitting together does not automatically make an organization more efficient. It is our ability to communicate that enables us humans to complete tasks collectively faster and better than alone. Over the millennia, this has even been enough to make us a ‘superior’ species. We should therefore value the ability to communicate.

Home office or remote work is a great thing, no question. I myself love working from home or the next café, and among other things, this article is currently being written from home. However, in our team, we have already noticed how this supposed privilege can also have negative effects. Namely, whenever communication suffers as a result. As developers, we work together daily on a ‘piece’ of software and want to find the best solution for our client. For all non-programmers, I have a small example here for clarification: imagine working together on a long document with dozens of cross-references and dependencies between individual text passages. And everyone is authorized at any time to change, move, delete, or add new passages (we programmers often call such changes refactoring). So why is (internal) communication so important? Exactly for this reason.

So how do I manage to reconcile flexible working models with good communication? Well, where there’s a will, there’s a way. Every developer must be clear about the significance and importance of communication. Ultimately, it is discipline that makes it a duty for each of us. An excellent source that I would like to share is the Management 3.0 book. In the Remote Working category, you can find countless interesting articles on the topic.

Now, to not lose the thread entirely and to come back to agile methodologies that support communication, I would like to point out a proven technique.

Daily Standup Meetings

We want to promote communication, so let’s simply set appointments. A practical solution that has now become established in almost all software forges is the Daily Standup Meeting, or simply Daily. The goal of the meeting is to briefly inform each other about the following three points:

  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What is hindering me?

It’s important to note that this should be a short meeting, and short ideally means 1-2 minutes per person. Too often, you suddenly find yourself in a heated discussion of a small group during the Daily. But that doesn’t mean that discussions are generally bad, because that’s exactly what we want to promote. However, in the context of this meeting, they are simply not purposeful. The exchange important for two people blocks the rest of the team and drags out the meeting, and we’re standing specifically to keep the meeting short. So it’s the task of the rest of the team to recognize such situations and accordingly continue the discussions after the Daily.

Team members working from home are also expected to participate in the meeting. This can certainly be formulated as an expectation and thus appropriately enforced. Technical communication tools like Skype make this easily possible nowadays.

digatus Daily Standup Meetings

Our developers at a Daily Standup Meeting

External Communication

Communication is not only important to us internally. The relationship with the customer must also be nurtured through mutual exchange. After all, we’re translating their wishes into program code. And even if the workshops were intensive, our Product Owner did an excellent job, and we discussed tasks thoroughly during Sprint Planning, questions will arise. The customer is an expert in their field. We want and need to use this expertise! Moreover, we want to maintain open and honest communication. Being agile means having no secrets. Errors and problems are not concealed but addressed.

When we ask questions, it doesn’t mean we weren’t paying attention in the workshop, but that we want to explicitly clarify requirements. I also like to call this ‘Oh, I thought that’-prevention.

Mutual Trust

This brings me directly to a point that is especially close to my heart and which, although often taken for granted, often comes across unintentionally but noticeably for us.

We always assume that everyone has done the maximum possible for them.

I was actually able to experience this point live. Our current team has grown into a powerful, stable unit over the last few months, where everyone knows that everyone is 110% committed to giving their absolute best. And it should be clearly stated that ‘team’ consciously and naturally includes our managing director. A colleague had technical problems that forced him to reinstall his system, which of course cost valuable time. The pending work could therefore only be processed the next day, which it was. During the course of the day, the responsible colleague was increasingly asked whether the tickets had already been processed. A completely legitimate and justified question that was asked in neutral language. To understand the effect on the colleague now, we need the Four Sides Model of Communication.

Communication Square Thun digatus

The Four Sides Model of Communication

It defines four effect sides of verbal communication, each at the sender and receiver end. This means that a message is transported to the receiver in four different ways and can also be misunderstood on four different sides. This model explains why the previously described situation led to misunderstandings.

The following messages were received respectively:

Sender:
Factual level: ‘Are all tickets processed?’
Self-revelation: ‘I want to know if all tickets have been processed.’
Relationship side: ‘We can do this, how’s it going?’
Appeal side: ‘Please tell me if you need help’

Receiver:
Factual level: ‘Are all tickets processed?’
Self-revelation: ‘I want to know when or better if you’re finished.’
Relationship level: ‘You’re too slow for me.’
Appeal level: ‘Please work faster!’

The message was completely misunderstood by the colleague due to the increased inquiries, although the actual intention was even positive and supportive.

Before I fall into the trap of just criticizing the situation without offering any improvement, I’d like to refer to my statement at the beginning. We always assume that everyone is doing the maximum possible for them. With this certainty, there is no need for constant inquiries. The work doesn’t get done faster because of it, but it may unintentionally foster resentment. Every project with us can be tracked almost live on a task board. This allows everyone to determine at any time how many tasks have already been completed. And if you still feel the urge to speak up, here’s a suggestion for an alternative formulation:

‘Hey, I’ve seen there are quite a few tasks, I hope you don’t feel under pressure. If we can help you, let us know. How’s it going?’

One last small thing: We’re not looking for someone to blame, but for causes.
If errors occur despite maximum effort, it’s important to note that no one alone is responsible for an error. Even if at first glance a culprit is quickly found, the situation becomes much more complex with increasing severity of the problem than originally assumed. But usually we stop analyzing at the first culprit and miss the chance to improve together and, above all, to solve the actual problems.

Conclusion

Communication is important because it makes us successful together and is therefore essential. In everyday life, however, a certain routine often creeps in and the importance of communication slips further down day by day. Especially in today’s times, it is important to pay at least as much attention to active communication as to completing one’s tasks. Thank you for reading!

Latest Posts

digatus technology GmbH successfully certified according to ISO/IEC 27001

IT and OT Integration in Acquisition Processes

Successful IT Carve-out at Trench: from Corporate Structure to Mid-sized Market Leader