I'm looking for advice from people who have experience with both US federal software environments and Whole Team Development, ensemble programming, or mob programming in that setting. I'm especially interested in how teams handled tooling, requirements, credentials, and security controls.
Were tools such as Microsoft Teams, Webex, Chrome Remote Desktop, mob.sh, shared VMs or VDIs, VS Code Live Share, JetBrains Code With Me, or similar screen-sharing and keyboard/mouse-control solutions approved? Did security teams initially object, and what controls or documentation helped address their concerns?
I'm particularly interested in situations where individual credentials must remain separate for activities such as promotion, production access, or administration. Experiences from different agencies and classification or sensitivity levels would be helpful, since the rules likely vary considerably.
4 Answers
The answer depends heavily on the agency, mission, system authorization boundary, and the sensitivity of the data. A tool that is acceptable in one civilian agency may be prohibited in a defense or law-enforcement environment. Government-approved versions of Microsoft 365 tools may be viable, while third-party remote-control or collaboration services often require separate authorization and may be disallowed entirely.
The safest approach is usually to keep the development environment, IDE, filesystem, and collaboration service inside an approved agency-managed network or VDI. Any external cloud service that can see source code, credentials, screens, or sensitive data will likely need formal review.
Security teams are understandably cautious about tools that transmit screens, source code, clipboard contents, or keyboard and mouse control. A proposal is more likely to succeed if it clearly documents data flows, where the service is hosted, encryption, logging, administrative access, vendor authorization, and how credentials are protected.
In practice, an approved internal Teams deployment or managed VDI may be acceptable, while tools that connect to an unapproved external service may be rejected regardless of how useful they are. Get the system security or authorization staff involved early, but bring them a specific architecture and risk-control plan rather than a general request to approve remote collaboration.
For pairing or mobbing, I’d look for a self-hosted or agency-approved collaboration platform rather than trying to justify a consumer remote-desktop product. Ideally, the code and files stay on a controlled shared server or VDI, with access governed by the organization’s existing identity, logging, and endpoint controls.
You also need to design around credential separation. Shared sessions should not let one person use another person’s credentials, especially for production, administrative, or promotion activities. The collaboration tool should support individual authentication, auditing, least privilege, and clear handoffs.
I’ve seen people assume that “federal environment” means one common set of rules, but the differences between agencies and systems can be substantial. A tightly isolated internal network may permit collaboration tools that would never be approved on an internet-connected or higher-sensitivity system. Even features within an otherwise approved productivity suite can have different authorization status.
So the practical answer is to identify the exact environment and authorization boundary first, then evaluate tools against that boundary. There may be no workable option for newer third-party tools, particularly in more restricted defense environments.
That’s exactly the kind of distinction I’m trying to understand. The challenge is finding approaches that preserve individual accountability without making collaborative development impossible.
That distinction is important—there isn’t one universal federal policy. The agency and the project’s data classification determine what is even possible.