When agencies say “we tried Agile software development, but it didn’t work,” often what they’re really saying is “we tried to outsource internal process improvement.”
Agile software development isn’t solely your vendor’s problem—to support the vendor in that approach, the agency must change how they work with that vendor. One of those changes: establishing two internal positions to support the development team. Without creating those positions, it’s easy to spend a great deal of money on an “Agile transformation” that transforms nothing, and could even make projects less likely to succeed.
An Agile project is unlikely to succeed without these two government full-time employees.
The first position: a product owner. This role is central to Agile—one person who represents the needs that the product is fulfilling. Their job is to align the needs of the users, business requirements, stakeholder demands, and technology to ensure that the product that’s being built will be successful. This person needs to have a deep understanding of the agency and the problem space. The product owner needs to be empowered to make rapid decisions about the product, without having to seek permission from bosses or governance boards, so that they can make decisions as rapidly as the software development team needs answers. Their days will be spent meeting with stakeholders, users, and the vendor team, and clearing blockers for the vendor team. Somebody cannot be a product owner under the umbrella of “other duties as assigned.” This is a full-time job.
Finding somebody who is empowered, knowledgeable, and also available to do a new full-time job is a tall order. Under rare circumstances (e.g. creating an entirely new benefits program) it’s possible to hire for this, but usually you need to select somebody already on staff, and backfill their position for the duration of the project. Sometimes there’s already a relatively senior person able to do this, and sometimes somebody from lower in the agency needs to be elevated to do this.
The product owner must be a government employee. This role cannot be outsourced. Why? To succeed, they need to already have deep knowledge of the problem space, they need to understand the agency bureaucracy, and they need to be able to command the time and attention of agency employees when necessary. They’ll own the knowledge of the vendor’s work, in enormous detail, on behalf of the agency. And the product owner will be the pointy end of contract oversight, as the agency employee who is responsible for affirming, at the end of each two-week sprint, that the delivered work adequately addresses the assigned user stories and meets their acceptance criteria. All of this means that the role of product owner is an inherently governmental function.
The second position: a technical lead. While the product owner ensures that the work is meeting the needs of its users, it’s necessary to have somebody ensure that the work is good, in a technical sense. Is the code written well? Is there adequate test coverage? Are the tests well written? Is the technical documentation sufficient? Does the work, in short, comply with the quality standards laid out in the contract? These questions must be answered constantly, throughout a project, and that requires designating somebody to perform the oversight to enforce those requirements. This should be somebody with enough experience that they’d be designated as a “senior software developer” in the private sector—somebody who hasn’t just written code, but been responsible for reviewing others’.
As a rule of thumb, a full-time technical lead can oversee the output of four “scrum teams”—the four- to nine-person teams that generally comprise Agile projects—though this can vary considerably. They’ll attend all scrum ceremonies, be available to answer technical questions for the vendor, and regularly spend hours reviewing the vendors’ deliverables.
This role cannot be outsourced to another vendor, and of course cannot be done by your primary vendor. Their work is a core part of contract oversight, and requires considerable ongoing coordination within the agency. It absolutely cannot be replaced by an independent validation and verification (IV&V) vendor. Unlike the product owner role, it’s reasonable to hire somebody new to serve as the technical lead, although it’s preferable to elevate somebody from within the agency, if possible. In practice, the technical lead often winds up working under the product owner, to ensure that the vendor has a single primary point of contact, and to maintain the supremacy of that single decisionmaker.
This is all easily described, but many agencies will find it difficult to execute, due to sclerotic hiring practices and antiquated position descriptions. U.S. Digital Response (USDR) can help with this! Our Talent Toolkit provides strategies, practical examples, and templates for attracting, developing, and retaining a high-performing digital service workforce, and we also offer direct support in the form of active assistance to governments in honing recruitment techniques and implementing hiring best practices.
In practice
At USDR, we’ve worked with agencies and departments at all levels of government in helping them hire these two full-time employees. Here is some of what we’ve learned about how this works in practice.
Designating a product owner is hard for any organization, because they don’t have a knowledgeable, empowered, experienced employee lying around, looking for something new to do full-time. It’s often easier for agencies to award a multi-million-dollar contract than to designate a product owner.
So how does it happen? There are two approaches that can work. First, we’ve seen lower-level employees elevated to this position, which works if and only if they are genuinely empowered and protected, clear up the leadership chain. If they are not actually given authority over the project, then they and the project are being set up for failure. Second, we’ve seen senior employees have their position redefined for a year or two to serve as the product owner, which works if and only if they are not also trying to do their other full-time job.
Designating a tech lead is easier, although it can still be tricky. Most government agencies have an IT team, and a subset of them may be capable software developers, even if using those skills isn’t part of their existing duties. We’ve seen IT folks reassigned, if only part-time, to the position of tech lead, though they often need to be given the space to grow into the job. They already know the agency’s IT environment, which can be a big help when supporting an external vendor team. The other viable approach we’ve seen is to hire somebody for this position. This is needed when there’s nobody with the right skillset, or the IT team doesn’t have the slack to reassign somebody part-time. If the project in question is improving or integrating with the agency’s existing IT environment, this person will need the time and relationship to get up to speed on that, but that’s not a tall order.
With both roles, we have seen that you cannot fake this, there are no clever work-arounds, you simply have to get good people in these roles.
Practical takeaways
It is common for government software projects to spend millions of dollars even after a project has failed, because there is nobody with both visibility into how the project is going and the power to effect change. Huge sums of money are wasted because of the inability to commit two full-time employees to a project.
A lack of capacity to control the work being done by a vendor is at the root of so many big-dollar failures. Whether using an Agile or waterfall approach, whatever title you give these roles, there is simply no getting around that it’s essential to have one empowered person who is in control of the product being created, and one person providing detailed technical oversight of the deliverables.
Conclusion
The time to get to work on identifying a product owner and a tech lead is at the same time as starting to plan the procurement. Ideally, you can empower and transition in your new product owner and tech lead before starting to prepare an RFP, so that they can shape the solicitation based on their knowledge and experience, and so that the larger project team can get used to the idea that these people will be running the show.
Let us know if we can help your agency! Our dedicated Talent team is ready to help you ensure that you have the roles and the people you need to make your big software project a success.
Additional Resources
- Links to related USDR projects or resources
- External resources
