Architecting a feature does not come easy. Unless you are working on a project by yourself you will need to organize your communication well to have all parts of the organization work together to achieve your goal. To be honest with you, I’m not that great at communication. I had to learn and overcome some of my personal flaws during that time. I am grateful that I had to do that as it took me outside of my comfort zone and taught me several valuable lessons. These lessons are as important in business as they are important in personal life.
Working on feature development usually requires good communication within the development team. Most agile practices aim to improve that aspect and put all team members in the environment that promotes communication – makes it necessary and frequent.
One lesson that I took is there is never too much communication. Do not ever be afraid of being redundant about bringing things up or following up on them. Don’t get me wrong – you don’t want to be malicious or annoying about it. Instead, check back in with your team and make sure that it’s alright. Err on the side of doing more. And if someone will ask you to tone it down – do that. Usually, it wouldn’t happen because we rarely are that good at communicating.
Why is this important? There are many cogs and wheels that are turning in the development machine. And we have to remember that this machine is comprised of people who can get caught up in tasks, can get overwhelmed, can get distracted, forget to follow up or update the rest of the team. All of that has happened to me and continues to happen almost on a daily basis. The goal here is to minimize those things and minimize its impact of the team and the body of work. That is why it is necessary to update people in chats on the status of your work, leave comments to clarify the status of a work item, or have impromptu calls to clear up confusion about tasks. The worst thing that could happen is that you will be responsible for blocking someone else’s work. It doesn’t take too much to clear things up and move along.
As you can imagine communication doesn’t just come in the form of talking to your teammates. It also sometimes requires you to bring other teams up to date on a task that you are working on. This communication has a slightly different dynamic. Whenever you bring other teams to discuss a problem or gain their insight, you usually have to communicate the whole context of the problem to them clearly and concisely. They do not attend daily stand ups with you, and often times are not even within the domain that you are working on right now. Therefore, being clear about what you need from them and what they would need from you is very important. In my case, I had to chat with people from several other departments to gain insight on the processes that my team was trying to improve and reuse. It was a big learning moment for me, because I had to talk to people I haven’t interacted with before and had to make those conversations productive.
One last piece of advice that I have learnt is – stay flexible. Even in the most defined features and architectures there will be times when requirements will have to change for one reason or another. That change will need to be discussed and communicated within the team and outside of it. Once the change is made it will be crucially important to update everyone involved in the process to ensure that there is no double work or misunderstandings on what, how, and why are we doing what we are doing. Staying on top of that will ensure that deadlines will be met, requirements will be satisfied, and team will remain performant.
Remember – there is no such thing as too much communication. Assume that position and adjust if necessary. Learn how to communicate well. Observe what worked well and what didn’t from your personal experience. Communication is a skill that can be learned. I hope that I continue to get better at it myself as time goes by.
Abstrakt Kode 