How to Build Agile Web Development Practices For City Government

The adoption of agile methodologies, at least within the WordPress and Drupal agency ecosystem, closely follows the Gartner Hype Cycle, a methodology charting the popularity of new tech. Prescriptive systems like Scrum with a capital "S" disrupted a culture that had operated for years on fixed budgets and waterfall Gantt charts. Agile evangelists like the one who trained me in 2012 had promised to fix so much of that and my expectations inflated accordingly. (I find the Hype Cycle so emotionally loaded, I had to make a gif about it.)

Image

When the agile approaches failed to deliver magical results, I plummeted into the "trough of disillusionment." That's where I was when I joined Pantheon in 2015. Back then, I often warned my co-workers at Pantheon about overusing the word "agile" because it had taken on a connotation of underdelivering among teams who felt burned.

Now, 10 years after my first Scrum training, I see more and more signs that the web development world is climbing the "slope of enlightenment" towards the "plateau of productivity." Take this interview with one of our strategic agency partners, Aten Design Group, and their colleague at The City of Raleigh, North Carolina.

Raleighnc.gov serves over a half-million website visitors per month. Over the years, the team involved has found a healthy balance of guardrails and freedom that is satisfying all involved. They are focused more on producing valuable work for the people of Raleigh than on prescribed processes. As Pete Weber, Communications Web Administrator at the City of Raleigh, put it:

"We do the work in digestible pieces, and at the end, you've got this massive website that's doing everything it needs to do for the public. Using Jira to communicate with Aten and get their feedback and engage with them is really helpful in managing such a large site. Especially when you have so many stakeholders coming at you on a day-to-day basis."

I hear that and I think of the early essence of The Agile Manifesto, which emphasizes "individuals and interactions over processes and tools." Yes, a lot of specific processes and tools are in play here, but they exist in the service of the individuals and the interactions. The processes and tools they work with to get features out the door (one-month sprints, Jira, Pantheon’s Multidev environments) are the means to an end, not the end itself. The end goal is to always improve the government's services for the people of Raleigh. Jira ticket numbers are  implementation details.

For agencies or website owners looking to replicate the success of Aten and the City of Raleigh, a few details from the interview stood out to me.

• Play the long game. Pete has worked with Aten for five years. Countless benefits add up over time as teammates learn each other's working styles and how best to collaborate.
• Iteration is key. Aten organizes its work in month-long sprints and sets a firm "pencils down" date by which features need to be passed along to city staff who perform deployments to the live environment on Pantheon. Instead of worrying too much about whether two weeks, or one month, or some other unit is the ideal sprint length, just pick what makes the most sense in your culture. Pete describes many other monthly rhythms in his work and it makes sense for Aten to match that cadence. Just switching from waterfall/relaunch mentality to an iterating-on-a-live-site mentality is an enormous win.
• Take time to get it right. You can work in monthly sprints and still plan ahead. The example issue we saw in this issue (a change to displays of calendars) was discussed back and forth for months before it was picked up for inclusion in a sprint. That timing was a reflection of other items being a higher priority in preceding months and the need for the discussion to get clarity on this specific change. Yes, you can always do follow-up work in a subsequent sprint if you find deficiencies. However, this team seems to have learned that given the number of stakeholders involved, there is a high likelihood of miscommunication. So they proactively work to ensure understanding before acting on a ticket.
• Show, don't tell. Pete commonly records videos that he attaches to individual Jira tickets, in which he screen shares and describes the behavior change that he thinks is needed on the site. That is a different tactic than the formally written acceptance criteria other teams leverage and ultimately any given team should pick what works for them. But if I imagine myself back in the shoes of an engineer working through Jira tickets, I would want a short video in which an authoritative voice who deeply knows the needs of different stakeholder groups describes what they expect in their own words. That would be more valuable than bullet lists of unknown provenance that spell out similar information.
• Review each feature change in isolation. In the full video, you can see the mapping from Jira ticket numbers to git branch names that appear on Pantheon’s Multidev environments. This separation enables Pete to review and approve work atomically. If one feature in one branch needs revision, that does not block the merging of another branch.
• Invest in technological strengths. Plenty of website work gets organized around fixing deficiencies. That pattern is especially common when work is laid out as a big upfront waterfall effort to build the site followed by maintenance and bug fixes. When teams instead work iteratively on whatever is of the highest value in a given month, they are more likely to find that investing in a particular strength is more important than fixing the next bug. On this project, that meant expanding the usage of Aten's Mercury Editor for all content types instead of just the few that needed it most immediately.
• Flex personal strengths. Similar to the way this iterative approach makes technological advantages stronger, it better leverages the strengths of individuals. This team has figured out that the effort to refine the details of individual feature requests that might commonly fall on the agency side can be tilted toward the City because Pete and his team have gotten very good at vetting ideas. As Aundrea Billings, Senior Project Manager, put it: "That just allows us [at Aten] to run and use your resources really well."
   

I would like to time travel this interview recording back to myself in 2016, when I gave a fiery (I remember it being fiery) DrupalCon 2016 presentation in Dublin. I was deep in the "trough of disillusionment" with agile methodologies and trying to find the way out. In retrospect, my advice then to "agile your agile" by making a backlog of agile methodologies and implementing them one by one was probably too literal to be helpful. Instead, look at The Agile Manifesto: "Uncovering better ways of developing software by doing it and helping others do it." Agencies like Aten who are "doing it" have found the way.

Read the entire City of Raleigh’s success story here.