5 Myths of Scaling Agile in Government

For federal organizations, every large systems development project has its own unique set of challenges. In adopting agile methods and frameworks, the challenge is how to scale agile for more complex development projects—with larger teams and systems, longer timelines, and diverse disciplines and operating environments.

Some federal organizations shy away from scaling agile, saying, “It just won’t work for us.” But that view is often based on misconceptions about how scaled agile can work in government. Here are the five most common myths—and the reality.

Myth No. 1: I’ll have to hire more people. I don’t have the expertise for all the cross-functional teams required to scale agile.

Reality: You already have the people you need. At many organizations, developers and other technical experts tend to work in functional silos. Scaling agile merely takes them out of those silos, and assigns them to individual cross-functional teams. The experts are doing the same kind of work as before—but the work is organized in a different way.

By working on cross-functional teams, people in one function gain insight into the value that people in other functions provide. This helps individuals collaborate more, and stay more focused on the organization’s larger goals.

Myth No. 2: I’ll need a big reorganization. As software developers and others move to “self-organized” teams, their current managers will no longer evaluate their performance, or help them develop their skills. That means I’ll need to reorganize to make sure someone handles those duties.

Reality: Self-organized agile teams are independent in that they control their own workflows. The growth of individuals should still be conducted by the people best suited to mentor and develop them; functional management doesn’t have to change, if what you have is working for you. What does change is that managers no longer must spend a large portion of their time on tasking. They also don’t need to evaluate the progress of the project—testers on the team take over that role.

In other words, managers are freed up to better manage their people, rather than the project. They make sure that team members are technically proficient and performing well on the project, or arrange additional training if they’re not.

Myth No. 3: The implementation will disrupt our delivery cycles. We can’t suddenly shut down everything for 2 weeks and take all our technical teams offline, to provide training and switch to a new software-development cadence.

Reality: You don’t have to shut down—or even slow down—to smoothly implement agile at scale. While you do have to take time to readjust, with the right planning you can work the training and cadence shift into your regular cycles.

Many organizations worry that scaling an agile implementation is a big, one-size-fits-all, one-time event that will overwhelm ongoing projects. The exact opposite is true. Implementation is gradual and closely tailored to project schedules, so there’s minimal disruption. There’s also constant support—initially from the outside, as agile is scaled—but then from your own people, as they gain expertise. You’re never left high and dry.

Myth No. 4: The PMO will no longer have a way to measure earned value. Scaling agile requires different control gates, and a different way of measuring project performance and progress—which could put us out of compliance.

Reality: Earned value is fundamentally about tracking what gets done. Nothing could be more congruent with agile!With agile at scale, we’re bringing that level of transparency and accountability to the whole enterprise, and we can keep tracking earned value for our technical delivery. What may change is that we’re inspecting our delivery much more frequently, and gaining even keener insights to our progress.

Myth No. 5: Agile at scale won’t stick in our organization. Our people have always done the same thing, the same way, year after year, and they’re not going to want to change. They’ll see this as just another flavor of the month.

Reality: Unlike many other initiatives, agile at scale sticks because it gives people what they really want—more of a voice in the work they’re doing. Instead of tasks being assigned to them from the top, developers and others play an active role in planning and decision making. Experience has shown that with this newfound responsibility, people become actively engaged in scaled agile. In a way, it’s what they’ve been waiting for.

This also benefits the organization. With more of a stake in the project outcome, people work harder for its success. In addition, people choose the skills they want to use and develop. Instead of managers putting them in roles they may not be suited to, people can do what they really love, and get great at it. This substantially improves the overall quality of work.

The reality is, scaling agile can be effective within large software development projects, and it’s much easier to implement than you think. There’s no need to hire more people, and organizations can plan the rollout along existing project timelines, so teams can adjust to the new development cadence over time. Though there are different inputs, performance and progress are measured in the same way. For team members, they’ll have more say over their skill set development and schedules, while managers can focus on their people and training, rather than the tasks at hand. A wide range of commercial frameworks, tools, and training are available to help your organization scale their agile approach to large software development initiatives. With the right expertise, success in scaling agile is right at your fingertips.