蘑菇视频

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鈥攚ith larger teams and systems, longer timelines, and diverse disciplines and operating environments.

Some federal organizations shy away from scaling agile, saying, 鈥淚t just won鈥檛 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鈥攁nd the reality.

Myth No. 1: I鈥檒l have to hire more people. I don鈥檛 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鈥攂ut 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鈥檚 larger goals.

Myth No. 2: I鈥檒l need a big reorganization. As software developers and others move to 鈥渟elf-organized鈥� teams, their current managers will no longer evaluate their performance, or help them develop their skills. That means I鈥檒l 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鈥檛 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鈥檛 need to evaluate the progress of the project鈥攖esters 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鈥檙e not.

听

Myth No. 3: The implementation will disrupt our delivery cycles. We can鈥檛 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鈥檛 have to shut down鈥攐r even slow down鈥攖o 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鈥檚 minimal disruption. There鈥檚 also constant support鈥攊nitially from the outside, as agile is scaled鈥攂ut then from your own people, as they gain expertise. You鈥檙e 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鈥攚hich 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鈥檙e 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鈥檙e inspecting our delivery much more frequently, and gaining even keener insights to our progress.

听

Myth No. 5: Agile at scale won鈥檛 stick in our organization. Our people have always done the same thing, the same way, year after year, and they鈥檙e not going to want to change. They鈥檒l 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鈥攎ore of a voice in the work they鈥檙e 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鈥檚 what they鈥檝e 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鈥檚 much easier to implement than you think. There鈥檚 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鈥檒l 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.