Learn how other customers similar to you, have benefited from partnering with us to co-create their digital transformation journey
Learn how other customers similar to you, have benefited from partnering with us to co-create their digital transformation journey
Principles like “software over documentation,” “responding to change over following a plan” and “quality interactions over tools” take on whole new meaning when managing remote teams.
Agile methodology recognizes face-to-face communication as the most efficient and effective means to share ideas. The benefits of sketching on cards or a whiteboard are two-fold — improving the level of understanding and reducing the time it takes to deliver the core message.
Most credit the adoption of Agile thinking as the primary driver to create more open, collaborative office spaces no longer punctuated by rows of cubes and team members appearing every so often. Open spaces led to more drive-by conversations between team members and more feedback collected throughout the development process naturally.
Unlike smaller teams who do have the option to co-locate, enterprises managing remote teams often don’t have the luxury of sharing the same physical space each day.
Team structure options:
Distributed teams must actively work to avoid falling into communication traps that shift the project process away from Agile development to a decidedly waterfall one. But, the world is a small place even for distributed teams — made smaller by the available communication platforms from Microsoft Teams, Trello, Slack, Jira, or Skype. Promoting the same close communication expectations is the key to supporting the Agile process on distributed teams.
Creating a culture where continuous integration is the norm is especially valuable on projects with extended timelines or while managing remote teams. In this structure, it’s easy to opt for dividing work for teams along technical boundaries. These technical boundaries may be divided by frontend/backend work or even database and services layer/frontend. Team bandwidth or security might drive the boundaries. Additionally, some businesses may be cautious of releasing intellectual property into a cloud-based platform like GitHub.
This usually results in the maintenance of two source code repositories with a commitment to merge them later. Resist this. The technical debt that results from this fractured code is more time-consuming to overcome than if the teams had increased the communication necessary to manage just one code repository in the first place. Overcoming any communication barriers to work on the same code base is worth it in every way.
The team manages successfully at leading remote teams and achieving this culture will begin to see evidence manifest in the daily communication and behavior of team members:
It’s easy to produce a giant spec instead of communicating daily with the remote development team or let distance become a reason to stay the course and avoid developing the solution when challenges or barriers arise.
Building on a weekly schedule is good, daily is even better. Hold your team accountable to submit a change set to the source code control each time. Then, take advantage of your compiler as a stand-in team member to ensure your source code has reached or exceeded quality expectations. Adding smoke tests can propel this even further.
Most people assume custom software development is a purely technical process. While it’s true the process is highly technical requiring years of training and experience to run successfully, software development is a human process first and relies on trust between individuals.
Promote knowledge sharing on every team. This is less about documenting processes in a Wiki and more about nurturing this behavior in daily stand-ups or any time team members give updates.
Support your team to share beyond what concerns to that day’s work. If a team member expects something they are working on may impact another role the next day, call that out. Once team members master the habit of sharing important, forward-looking insights, that’s when true knowledge sharing has been reached.
Fostering close collaboration between designers and business analysts, urging extra attention to the graphical interface. This mean additional time is spent creating visual artifacts for the technical team to complement related user stories. The prize? Less questions related to aesthetics and less iterations created as a result of the mismatched expectations.
For teams who are co-located, it’s easy to address questions around performance and scalability as they arise. Imagining and documenting requirements with the appropriate level of detail serves as the link between the business and technical teams.
For distributed teams, understanding non-functional requirement feature plays an even bigger role. Without specific directions documented for the technical team, it might result in the production of an architecture that makes assumptions about the non-functional requirements resulting in increased rework, and time waste later.
While all Agile teams strive to write “just enough” requirements, managing a distributed team means accepting “just enough” may still mean documenting more than would be created for a co-located team.
Distributed team members can’t quickly sketch on a whiteboard to work through a complex concept. Rather than leaving your development and testing teams left guessing on the nuances that would otherwise be delivered verbally, document them and “give the answers” before the test.
By augmenting user stories with test or acceptance criteria you can set the technical team up for success without drastically expanding the narrative.
When teams are co-located, the level of communication needed escalates naturally. It might begin with co-workers speaking one-to-one in the breakroom. If clarifying details are needed, additional subject matter experts may be pulled into the conversation. Then, the conversation shifts from many-to-one or many-to-many, depending on the context. Maintaining this escalation process is essential to create outlets for quick answers or more in-depth conversations despite any distance that may exist between team members.
Types of Communication
The ability to ask quick clarifying questions is inherent in how most teams work. In the past, this could be accomplished with face-to-face drive-bys in the office. But, increasingly even teams who are co-located are relying on instant messenger or video calls to accomplish this.
Instant messaging is a powerful tool for managing remote teams that include non-native English speakers. The tool allows them the space to craft replies without the pressure of discussing directly (and quickly) with a native English speaker. That said, tools like Microsoft Teams or Slack allow for escalation from messaging to voice and video calls and even screen sharing if needed.
While the importance of instant messaging cannot be over-emphasized for distributed teams, watching body language and physical reactions to comments or questions are also critically important, especially when discussing challenges or questions to estimate feasibility or understanding.
No digital tool or communication strategy can replace the determination of the leaders needed to achieve the Team highest potential.
Co-Innovate with us.
Towa Software – Boosting Digital Transformation with best ROI – Remote Tech Teams. 300 strong.
