This is the first of a three-part blog series about:

The U.S. Federal Government’s practice of implementing hybrid-Agile/”Agilish” software development projects

The perils of Agilish projects

How we can make Agilish projects more Agile

You are likely reading this because you are looking for a way to make Agile work within the byzantine world of government/public sector Information Technology (IT). My perspective comes from more than a decade of working with the U.S. Federal Government implementing software systems using Agile. I have spent a good portion of that time working in “hybrid-Agile”, “Scrumfall”, “Agilefall”, or “Agilish” projects. My advice: Do your best to avoid Agilish projects.

Reasons to Avoid Agilish Projects

Look, I get it. You are likely getting conflicting direction from your government agency or client. They want Agile’s speed and flexibility with traditional project management or “Waterfall” project controls. They want end users to have greater say in shaping solution features during development, but award firm-fixed-price contracts and require adherence to inflexible program baselines. Even when agencies use “Agile-friendly” contracting rules, contract language and oversight requirements often impose Waterfall processes and reporting requirements.

The problem is that you can’t have your cake and it too. There is no free lunch. <Insert another hackneyed phrase here> In trying to be both Agile and Waterfall, most Agilish government projects toss agility aside to accommodate established project management processes. I now discuss concrete reasons why Agilish projects are a bad idea.

Agilish isn’t a Real Thing

Hybrid Agile or Agilish is not a recognized software development approach. It is an project management approach to Agile without roots in proven Agile or software engineering practices. There is no standard framework (like Scrum) or body of knowledge (like SAFe or PMBOK) for Agilish implementations. Without standards or best practices, you’ll be making up your own Agilish implementation as you go. The same goes for contract firms that claim expertise in hybrid-Agile.

Predictive vs. Adaptive Planning

In traditional project management, the bulk of project planning happens before and immediately after the start of a project. This is a predictive planning approach. Predictive planning assumes the next project will be similar to previous projects. Thus, it is possible to estimate (predict) the amount of work (scope), necessary resources, timeframes (schedule), and cost (budget) of the next project based on historical data and experience. This assumption is fine for routine and relatively simple projects but breaks down for more complex, technically challenging, or innovative projects.

Agile planning is adaptive planning. In Agile, planning and management of risks and opportunities occur throughout the entire effort. Decisions are based on lessons learned and insights gained during development. This allows Agile teams to, “Welcome changing requirements, even late in development.”

The Worst of Both Worlds

Mixing Waterfall with Agile yields the worst of both worlds. You introduce predictive planning and project controls (e.g., Earned Value Management (EVM)) that sap the Agility out of Agile while lacking detailed program baseline data necessary to measure project progress and apply project controls a la Waterfall.

Agilish from the Start

In government institutions, the shift away from traditional project management to Agile is rarely, if ever, a bottom up initiative. Most likely, your agency or government client decreed Agile as its preferred or official software “project management” approach. Such pronouncements usually mark the beginning of Agilish projects.

Agile, and its most popular implementation, Scrum, are not “project management” approaches at all. Agile is an umbrella term covering multiple approaches (e.g., Scrum, XP, Kanban, Crystal) to building and delivering complex technical systems. These approaches share the tenets of the Agile Manifesto and its foundational 12 Principles of Agile, which I paraphrase and distill below:

Teams develop and deliver system capabilities iteratively and incrementally within short timeframes
Empowered teams manage their own work and work at a sustainable pace
The measure of progress is delivery of valuable capabilities rather than alignment to plans
Direct and ongoing collaboration between and among technical, organizational, and customer stakeholders largely replaces formal documentation

Agile is a vision for a way of working, not a way of managing work or workers. Scrum is a lightweight framework of roles, rules, and best practices that embody the tenets of the Agile Manifesto and the principles of Agile. Characterizing Agile or Scrum, or any other flavor of Agile, as a “project management methodology” virtually guarantees Agile adoption failure.

Software Development Has Changed

Most enterprise software solutions are complex systems that change and evolve for as long as they are operational. Agile and DevOps enable this ongoing evolution by:

Decreasing the time it takes to develop, test, and deploy new software capabilities
Increasing the frequency of new software capability deployments
Automating Operations and Maintenance (O&M) activities

Agile and DevOps allow organizations to move away from deploying large software releases periodically or infrequently towards continuous flows of software feature releases. A strong DevOps culture fosters:

Close collaboration between developers and systems operations personnel
Automation of system deployment, monitoring, alerting, and troubleshooting activities

Agile does away with discrete Waterfall phases for planning, analysis, design, testing, and deployment followed by a long O&M phase. All of these activities happen in Agile, but occur continually and in rapid cycles, thanks to DevOps. Information and insights gained during these cycles inform how solutions evolve and how teams improve technical quality and team processes.

Agile and DevOps open the door to a different way of working. DevOps enables software development teams to deliver increments of valuable functionality sustainably and when needed rather than on a set schedule. As the speed and frequency of releases increase, scheduled project start and end dates lose their significance.

We move into what some call a “Software Development as a Service (SDaaS)” model. Instead of standing up new projects, agencies augment available software development teams or form new ones. The additional software development capacity adds to the existing software development flows. Agencies have the choice of adding technical contributors as agency hires or contractors. By treating software development as a service capability, organizations are able to ramp software development capacity up or down depending on mission needs and budget constraints.

Conclusion

Acquisition of software systems by the U.S. Federal Government is transitioning from a traditional project management approach to Agile. Over the last five years, the Federal government has enacted significant statutory and policy changes to align acquisitions and contracting processes with Agile and DevOps. Unfortunately, this transition will take time due to the complexity of Federal acquisitions and contracting and the resulting decades-old predictive planning culture.

In the part two of this series, I’ll talk about the reasons why Federal software systems projects become Agilish and the resulting problems. Part three will cover ways to make Agilish projects more Agile.

Let us know what you think!!!

A university professor visited a Zen master to learn about the master’s teachings. While the master quietly served tea, the professor lectured him about his studies in Zen philosophy. The master continued pouring tea in the professor’s cup after the tea spilled over the rim. The professor watched the master spill the tea until he could no longer hold back. “It’s full! No more can go in!” the professor blurted out. The master stopped pouring, looked into the professor’s eyes and said, “This is your mind. How can I teach you what I know unless you first empty your cup?”

Many versions of this Zen parable exist. They all boil down to the same moral: People who are unable to set aside their preconceptions and prejudices, who are wrapped up in what they know or think they know, shut themselves off from new knowledge and insights. Often, as we navigate through our lives accumulating knowledge, experiences, and developing points of view about everything, we reach a point where the boundaries of our mental models harden and our thinking becomes similarly sclerotic. In that state, we immediately reject or subconsciously distort anything that challenges our understanding. To truly learn, we must be prepared to understand new concepts on their own terms before interjecting our own perspectives. We must empty the cup so we may taste the new tea.

This parable is not an appeal to suspending critical thinking or disregarding previously acquired education, training, and experience. Indeed, those attributes are critical to the ability to learn new concepts and effectively apply them in the real world. It is a defense of a true open-mindedness that seeks to fully understand unfamiliar ideas before casting judgement on them or attempting to change them to fit preconceived notions or entrenched habits of mind.

“Hybrid Agile”

Most Federal Government Agile system development efforts are really “Scrumfall” implementations, where software development teams perform Agile-Scrum practices/activities within a Waterfall program management structure. This Agile anti-pattern is often colloquially referred to in the Federal Government as “Hybrid Agile.”

Hybrid Agile is not a recognized software/systems development approach. It is an ill-conceived and counterproductive approach to Agile rooted in federal acquisitions culture rather than in proven software/systems engineering practices. It is an attempt to gain the benefits of Agile while avoiding internalizing and applying the “Agile Zen” or principles that make Agile work. Rather than reevaluating existing processes to achieve greater agility, federal project management organizations typically choose to contort Agile processes so they fit within existing management, acquisitions, and contracting culture. This leads to a tailoring of Agile practices that is misinformed by traditional federal management biases. As a result, federal departments and agencies seldom achieve the reputed benefits of Agile software development.

This bias towards Waterfall-based management of software/system development efforts is systemic and rooted in the laws, policies and regulations (LRPs) that govern federal acquisitions and contracting. These precepts will not change overnight. However, waiting until they change is neither desirable nor necessary. Enough flexibility exists in the Federal Acquisition Regulation (FAR) now to reverse this bias and achieve real agility in how software-based capabilities are developed, fielded, and maintained. New acquisition and contracting practices are in place and in use today that align, rather than conflict, with Agile principles and practices. Finally, Agile thinking has evolved beyond its application at the software development team level to scaling it across both the IT and organizational enterprise.