Skip to main content
Return to Blog
The U.S. Digital Service, shown above, is one of many federal agencies applying agile development to improve IT projects at the federal and local levels of government. (Photo credit: USDS)

This article was originally published by the National Environmental Health Association’s (NEHA) Journal of Environmental Health in its November issue.

Editors Note:

A need exists within environmental health agencies to increase their capacity to perform in an environment of diminishing resources. With limited resources and increasing demands, we need to seek new approaches to the business of environmental health. Acutely aware of these challenges, NEHA has initiated a partnership with Accela called Building Capacity. Building Capacity is a joint effort to educate, reinforce, and build upon successes within the profession, using technology to improve efficiency and extend the impact of environmental health agencies.

The Journal is pleased to publish this bimonthly column from Accela that will provide readers with insight into the Building Capacity initiative, as well as be a conduit for fostering the capacity building of environmental health agencies across the country.

The conclusions of this column are those of the author(s) and do not necessarily represent the views of NEHA. Darryl Booth is senior vice president and general manager of environmental health at Accela and has been monitoring regulatory and data tracking needs of agencies across the U.S. for almost 20 years. He serves as technical advisor to NEHA’s information and technology section.

You are an educated professional, a leader, a driver of business and pro- cess improvement. You bring experience and passion and intuition. In our professional lives, however, we’ve each certainly observed or led projects that flopped in part or in full.

You might never lead a multimillion-dollar software project, but you will lead or participate in important projects. This column introduces a method for approaching projects of any size and for reducing risk. The method is known as Agile.

Agile got its start in software development where—and at great effort—project requirements were routinely specified in writing before programmers or users got a first peek.

When we run projects where half or more of our budget is spent writing requirements before our users are engaged, we bear the risk that the result won’t delight our users. Then, because these project budgets are often fixed once initiated, there’s no capacity to go back and redo (or even optimize) what was delivered. This method is known as Waterfall, a metaphor to illustrate the idea that once water—or in this case, project planning— cascades beyond a certain milestone, there is no going back.

Yet, even with Waterfall’s potential pitfalls, most government procurement rules are wired to get the whole project (the requirements, timeline, budget, and team) locked in far in advance. In the April 2018 Journal of Environmental Health, we pro- posed methods to hack your system implementation. Agile takes these hacks to the next level and is steadily becoming the new norm in local government.

At its essence, Agile means taking a project into smaller time-boxed sub-projects. These sub-projects can be as short as 2 weeks, with each defined, completed, and potentially delivered individually. Then subsequent iterations, naturally, reflect the user feedback and priorities from the previous iterations. The expectation is that circumstances will change, priorities will shift, users will change their minds or become more in tune as they observe work to date, and negative impacts of any misjudgment are generally limited to the smaller work periods. It’s wading into the swimming hole instead of diving.

Figure 1 identifies the component parts of each smaller iteration as projects are designed, developed, tested, deployed, and reviewed. The whole project is bookended by planning at the beginning and launch at the finish.

Do not think, however, of Agile only in the context of software development. Terms like deploy and launch apply to health interventions or placarding projects or fee proposals. In fact, the methodologies can be applied to any project. I’ve used Agile for technical documentation, marketing campaigns, and even training.

To illustrate further, let’s imagine a fictional scenario where a local health department applies Agile to a grading or placarding project.

Fictional Scenario: Great Health County Launches Placarding for Retail Food Facilities

Whitney Waterfall
In a Waterfall mindset, Whitney, a health department project manager, meets with stakeholders and plans the entire project from initiation to a 1-year, post-implementation assessment. All the tasks—which- might include outreach, ordinance, board approval, research, system design, placard design, printing, training, communications, launch, and a one-year assessment — are listed end-to-end (perhaps with some overlap). She’s proud of her Gantt chart and makes a proposal to the health officer. The project is green-lighted, resources are assigned, and the project kicks off with regular hour-long status meetings where the fixed plan is updated with status changes, slippage, etc. The meetings usually run long.

Whitney’s project proceeds as similar projects do, with some setbacks and some successes, some scheduling challenges, some resourcing problems, and (hopefully) a final product. Almost certainly she’ll use the entire timeline and budget (maybe more) and strive to hit every requirement conceived of the year before.

Angela Agile
In an Agile mindset, Angela, a health department project manager, sits down with stakeholders and builds a backlog of all the things the department wants or needs. Those items that might take longer than two weeks (the smallest work period to which the team commits to) are divided into smaller tasks that will take less than 2 weeks. The list is ordered and can be augmented and reordered with each iteration. Nothing is fixed in stone. There’s no obligation to complete the entire list since some things might naturally fall off as not important.

Angela’s deep understanding of the domain allows her to order the backlog to maximize return on investment (ROI) and reduce risk. For example, one might say that designing the placard has the highest priority because it’s a tangible representation of what is being proposed, useful in training, and requires approval. On the other hand, if the placard design takes 2 months to complete, costs $10,000, and the board of supervisors declines the necessary ordinance change, the $10,000 and the time are lost.

Instead, Angela might create and prioritize a smaller task such as “collect existing placard design from neighboring health departments as likely representations of what our community has already embraced.” The cost is nearly zero but the task still facilitates the proposal, training, and communications and outreach.

Angela forms a small team (just those people likely needed for the several items at the top of the ordered backlog) and the team decides how much work they can accomplish and deliver in two weeks.

The team meets daily for a very short stand- up meeting to convey what was completed yesterday, what activities will be completed this day, and what, if anything, is holding the team back. If one team member finishes early, they jump in to help others. If the team completes its commitments early, the team adds items from the ordered backlog. At the end of the work period, the team reconvenes, delivers its work product, and Angela augments or reorders the list for the next work period. In this way, the project proceeds iteratively.

Angela’s project exploits continuous learn- ing, taking on new requirements and removing others. Small tasks and nimble teams expect continuous feedback from stakeholders. The final product doesn’t look exactly like what was originally envisioned—it looks better! The team discovered that there was no need for an ordinance change and that they could easily clone and tweak a neighboring health department’s design, training materials, and any other relevant components. The savings allowed for more outreach and a hap- pier customer.

Conclusions and Next Steps

Short bursts of tangible deliverables are energizing to teams. The license to freely reconsider (i.e., add or remove) the requirements mitigates tough conversations about making compromises. And finally, the overt focus on customer satisfaction is very rewarding for all. Review the additional resources in the sidebar and let’s see if Agile has a place in your next project. Continue the conversation in the Building Capacity in Environmental Health Group on LinkedIn.

Or, to learn about digital tools that improve Environmental health, visit Accela’s Civic Solution for Environmental Health here.

Agile Resources

Corresponding Author: Darryl Booth, Senior Vice President and General Manager of Environmental Health, Accela, 2633 Camino Ramon #500, San Ramon, CA 94583.
E-mail: dbooth@accela.com.

Return to top