An Assessment of Remote Development Teams

Across the world, organisations are adapting to working remotely. For some organisations this is new, and for other organisations, it’s something they are well versed in. At Patient Zero our preference and our clients’ preference has typically been to work face to face in our clients’ offices. 



We’ve been carefully looking at the effectiveness of remote work for our software development teams since we moved to remote working in early March 2020 due to COVID19. In order to assess how our teams are going, we investigated a range of factors to try to give us an indication of how our teams’ performance may have changed during this period. We carefully watched velocity, burndowns and sprint stability. We actively sought out our teams’ and clients’ feedback in group settings and one on one. 

All indications so far show that PZ development teams are just as effective remotely, as they are face to face, in fact, they may work better remotely.

We wanted to understand why our teams were successful with remote working, while our customers reported challenges and communication break downs on other projects. From our research across 6 PZ Development teams operating in a wide variety of technologies and industries we have distilled the feedback down to these key factors:

1. Governance

At PZ our Way of Working sees clients actively involved in reviewing and prioritising the backlog. They are also involved in approving the start and accepting the result of each sprint. When we moved to remote working, these approval practices easily translated to teleconference. Our clients reported their teams struggled to confirm their backlogs, verify priorities and get approval from stakeholders when working remotely, PZ seemed immune due to our strong governance practices pre-existing the shift to remote work.

One of our clients commented "What has worked better than expected is working remotely, we didn’t notice any change in velocity. The way the team is working in the our environment, as hybrid team of our people and PZ people together. We’ve even used a number of PZ ways of working to get our internal teams working better remotely."

2. Sprint Milestones

PZ Development Teams as a Service operates sprint milestones. Our clients’ deadlines depend on successful sprints and we are invested in successfully completing the same sprints! When we shifted to working remotely, our teams still retained their focus on ensuring successful kickoff of approved sprints and successful delivery of quality sprint goals. We found that Showcases worked even better remotely and afforded a chance to record and share with those who couldn’t make it. The chat capability of video-based showcases maximised feedback, giving those shy people a chance to ask questions during the presentation.

3. Reduced Spin Up Time

We’ve had clients suggest their concerns about forming a team remotely to take on a new challenge, citing the concern of an increase to ramp up time as these teams must agree on processes, technologies, scope, priority along with forming mutual bonds. Our pre-configured cross-functional teams are built with significant care. We monitor 17 factors when assembling teams. Ensuring we have the right technical skills, cultural alignment with the client and the ability to work together. We add to this our fully formed PZ Way of Working which ensures team members know their roles and play to position well. As a result, we established multiple new teams to take on new projects entirely remotely. Our clients received working software, great documentation and full suites of automated tests with their delivery on time and on budget with the additional scope included! Projects which kicked off remotely ran smoothly, the governance practices aided this by enabling us to start producing valuable work remotely as quickly as face to face.

4. Transparency

PZ teams practice absolute transparency in their delivery model. This transparency is provided daily insight via telemetry and metrics to monitor and also at the end of sprint showcases. Our teams track a range of critical metrics.

Each sprint we continued to measure:

• Velocity (sum of points completed) – this largely remained constant or trended upwards
• Unit test Coverage – our teams naturally aim for 70% coverage
• Automated UI Test Coverage – our teams must end each sprint with tests passing
• Load/Performance Tests – our teams end each sprint verifying these results 
• Changes to the sprint plan – our teams are trained to carefully handle changes to sprint plans

As an example, the following is the Velocity Measurements from an 11-week project started remotely with a team who had not worked well together before. Sprint 0 was 1 week to get tooled up, environments available, and familiar with the new domain. Each subsequent sprint was closed and accepted by the client with a consistent velocity: 

Each day during a sprint we:

• Ran standups and escalated issues through our PMO
• Shared our burndowns with PZ