Many people think that Agile simply means faster, but Agile is not just about speed but about value. Our Federal clients get the things they need the most, first, and it's adherence to Agile processes and ceremonies that allow us to A) understand what they need and B) deliver it efficiently. Is Agile faster than a traditional waterfall approach? Sure, but it’s delivering value that matters most. Fast delivery of products that don’t help end users and the agency is obviously a poor outcome. Embracing thinking and processes prevents that from happening.

I've been at TCG for well over a decade, and we have successfully implemented Agile in a lot of different contexts. Federal agencies are not all the same, differing in culture, tech stacks, budgets, and everything in between. Our approach is to meet agencies where they are, given all those variables. We seek to understand, and this means making sure our Agile practices give the Federal stakeholders on our projects a strong voice. You can't just impose Agile ceremonies or do them in silos separated from users and product owners and expect to gain all the benefits. 

There's the important and obvious things like improving delivery timelines, helping organize and streamline sprawling application portfolios, and breaking down communication silos. 

The level of communication improves, collaboration improves, level of transparency into the process increases–what teams are doing and project status becomes much clearer through Agile. This enables leaders to make better decisions about development efforts because the information available is better. Agile also incorporates capacity management, leading to optimal resource utilization, which facilitates smooth modernization.

Our DevSecOps solutions are right sized for the organizations that we work with from a one developer team to a twenty developer team. With larger organization, development and other teams are more likely to be dependent on other areas. This creates large islands, and more time is needed to build bridges and establish collaborative approaches. Small agencies need to do more with less and teams are much smaller and more integrated. In that situation, we would focus on automation first. The bottom line is that we know how to adjust our approach given the organizational needs. 

I think the GovCon industry is still behind on the issue of open-source supply chain security.

When we incorporate third-party dependencies into a project, the reliance on external repositories and sources introduces risks of malicious or vulnerable packages. This, in turn, jeopardizes system security and integrity. Taking cognizance of this, library management has evolved to implement mechanisms aimed at safeguarding software supply chains. This is where Protective Sequestration (PS) comes in, a concept borrowed from public health that describes measures taken to prevent the infection of a known uninfected group from a potentially infected larger group.

At its core, PS entails taking stringent measures to insulate an uninfected software repository from potential risks. This is achieved by initiating the standard process to download updated versions of packages, used directly or as dependencies in projects, but then intentionally isolating them for a ‘quarantine’ period before being incorporated into the supply chain.

As with our other capabilities, we have an iterative approach. We don't come in and try to overhaul everything . We focus on high priority problems first and iterate from there. This preserves institutional knowledge, delivers valuable changes quickly, and saves money in the long run. This approach also helps avoid disruptions to current development cycles and updates.