Our clients are concerned about milestones, deadlines, and commitments to leadership. Essentially, they care about what is going to be done and by when. This creates a concern that Agile is too flexible and that there is no room for long-term planning. Although long-term planning and road-mapping should absolutely remain flexible, they are still an important part of Agile, enabling us to build the right things quickly and adhere to contract/project goals. 

Our Agile process for each client is developed in an Agile manner. We learn about how a Federal client works—what their process needs are—and adapt our approach to their organizational context. We are well versed in implementing Agile principles in a world where regulatory, policy, and contractual deadlines exist.

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 top items like improving delivery timelines, ensuring applications meet requirements, and breaking down communication silos. Our approach also ensures that our clients get an increasingly clear picture of how well the applications in their portfolio are supporting their mission goals. In addition, we help Federal agencies manage their application portfolio in an Agile manner, eliminating sprawl, shadow IT, and redundancies. 

Overall, the level of communication improves, collaboration improves, and the level of transparency into the process increases—what teams are doing and project status become much clearer through Agile. When high-quality, up-to-date information is available, leaders make better decisions about development efforts.

Our DevSecOps solutions are right-sized for the organizations that we work with, ranging from a 1 developer team to a team with 20-plus members. There are different needs at different organization sizes. With larger organizations, development and other teams are more likely to be focused on their own internal deadlines and objectives. This creates large islands, and more time is needed to build bridges and establish collaborative approaches. Small agencies need to do more with less, so teams are much smaller and potentially more integrated. In that situation, we would focus on automation first in order to improve efficiency and quality. The bottom line is that we know how to adjust our approach given the organizational needs. 

I think the industry is still coming to terms with 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 potentially jeopardizing system security and integrity. Taking cognizance of this, library management needs to evolve 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 a software repository from potential risks. This is achieved by initiating the standard process of downloading updated versions of packages, for use directly or as dependencies in projects, but then intentionally isolating them for a ‘quarantine’ period before incorporating them into the repository.

As with our other capabilities, we take an iterative approach. We don’t come in and try to overhaul everything at once. 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.