Distributed Teams in a Post-COVID World

We are over two years into the pandemic and the foreign feeling working 100% remotely is no longer foreign. It has come to stay. We get up in the morning, grab a quick cup of coffee and almost immediately throw ourselves directly into work. 

At an individual level, things aren’t too bad. But at the management level, things got a whole lot more difficult. The management of people, and the engineering team’s Sprint size volume of work requires a much different approach. 

Since going remote, the interpersonal communication within the team has increased, especially in one-on-one conversation. However, most of these conversations are done in many virtual channels and are not invisible to the managers. With that in mind, how do we now distribute work, keep track of progress, and validate results?

The truth is that most managers have reverted from their trust centric models working with the teams to micro-management. Unable to track progress unless asked, many organizations went back to single threading the implementations. One person – one story, until the story is done. The result is that Sprint after Sprint multiple stories are carried over and there is no clear indication when something will be done. 

Sprinkle in the manual and custom nature of how every manager reports their team’s progress, and manager’s personal need to demonstrate successes to be recognized for their ability to manage the team and the recipe for projects going off schedule, taking more time, and exceeding budget is reached. No wonder that over 30 years in evolving software management disciplines and migrating away from waterfall models, we’re back to square one – observing a staggering 66 percent of technology projects result in total or partial failure. 

What can we learn from this? Well, number one is that most successful projects are executed in a team environment, where comradery and peer pressure are packaged into a single behavior element pushing all the team members to succeed. 

If the nature of your team’s behavior after moving to fully remote operations led to the team dissolving into a group of single contributors, take notice.  While a single contributor environment may also deliver results, it rarely scales and comes with its own set of challenges. As with any single contributor development, there is a lack of knowledge transfer, scope, design, and implementation review so much so that its not uncommon to see Stories in iterative development cycles stuck in an unknown state without a clear understanding of “how much time is needed to complete” and “when the story is expected to be delivered to QA”. As if overnight every team member became an individual contributor. 

After all, if there is nobody to cross check and ask questions about a single contributor’s progress and gauge the scope of the work left, the manager’s left with only two options. First, trust that the engineer is providing accurate estimates and timelines. And second, constantly nag the engineer to report the progress.

So, what is the right answer here now that we know that fully remote work is here to stay and will likely remain the main type of environment for engineering teams? The answer, a new type of solution that raises the aspect of collaboration to a whole new level. A solution that not only helps engineers estimate the size and scope of their work and intuitively report real-time progress, but also a solution that helps drive accuracy to the estimation and delivery progress without any micromanagement. 

Is there such a solution? There is, and if you’re reading this article, we’d love to encourage you to explore Project Simple.

Honest Conversation with an Agile Purist