Why Agile Website Support is the New Normal

There are countless discussions online about agile software methodologies, and how these are used to develop products. But there are fewer discussion on agile website support. Non-agile software development all around is becoming more and more endangered. It's turned out to be unwise, costly, and ultimately dangerous, especially in a support and maintenance context.

Let’s face it, for development agile is the new normal.

In some slow-moving branches of the defense industry and government, you’ll find waterfall. But save these, virtually every organization developing software adheres to some form of agile. In fact the few outliers that do not are far more likely to move into the unconstrained extreme of cowboy coding than the antiquated principles of waterfall.  

Today’s embrace of agile development isn’t a fad. It's a consequence of trial, error, and results in the real world. Virtually every developer has worked with some stringent pile of initial requirements that took a good chunk of time to extract. They then found that these requirements were not adequate for creating a working product. It follows that creating software based on quick releases and constant customer feedback is the way to go and there’s no going back.

Just consider what non-agile website support looks like.

Way back when, old school support was a function performed when the product reached maturity. Support personnel or web support experts were never intended to think like developers who embrace a cooperative and creative mode. These supporters were thought of as maintenance workers who are expected to rush out and promptly fill in potholes as they come up.

There are several formal disciplines meant to give structure to the IT support process, and none of them pay any heed to the creative or collaborative spirit of today’s software developers. This old way of doing things creates an environment of indifference.

Non-agile website support is, in a word, “unempathetic.” And this is often what’s described by clients who aren’t happy with their website support services. Support teams aren’t inclined to feel any ownership over the product. The priority for support bugs sometimes being set by teams like sales or marketing, which have very little insight into the scope of technical issues and to-do’s.

Development teams are inclined to throw problems over the wall and only focus on the fun aspects of coding. without thinking about long-term consequences or the customer's end goals. This also means that support teams are unlikely to feel challenged, and have there’s a higher risk of turnover due to lack of engagement which in turn creates silos in which front-end and back-end development, quality assurance engineers, and others seem as if they are working in entirely separate companies. Together all of these problems converge into massive amounts of spinning and lost productivity.

Enter onto the scene agile website support.

How do we avoid this mess?  There's nothing stopping us from applying the agile methodology to the support process; these go hand-in-hand. The initial concern is for a support team to adopt agile, they need to include highly effective discovery processes and customer severity into their workflow and center everything on this. And with this, let's examine what agile website support looks like.

This does away with the old approach of an all-powerful manager vetting issues and handing them down for the support team to dutifully fix. Rather, the support team works with the product owner, or even better: the Customer Success Manager (CSM). Developers then review the scope with the CSM and take ownership over bugs within the agreed-upon sprint timeline.

In this scenario, high-severity product issues have a more direct and visible impact on the sprint schedule. This entails is a greater sensitivity from the development team towards introducing bugs that may cause product delays—remember, there's no throwing anything over the wall or into the backlog.

There's a constant flow between developers and QA engineers. Not only does this foster much tighter collaboration across the board, it ensures that support teams get to watch over a much less error-prone code base. Rather than getting bogged down by countless small annoyances, they can focus on the issues that seriously impact the customer. It’s all about empathy.

Within agile support teams, developers end up working closely on the same code base. Maintaining daily or scheduled, frequent builds—a practice that enables reliability—become mandatory.

In the traditional support methodologies, the priority of bugs gets influenced far too much by whichever customer or outside team yells the loudest. It’s like a squeaky wheel principle. This induces stress and fosters unrealistic expectations. By fixing the support window to three or four weeks (or an agreed upon alternative) as mandated by agile, the support team gains a realistic timeline for resolutions, while being able to offer a hard delivery schedule.

Better yet, the incoming fixes become transparent to the development team and do not end up becomming a source of friction as in non-agile software development.

Our examples? Open Source support for Drupal and WordPress.

Let’s look at a specific domain in which agile support can make a massive difference: Drupal or WordPress agile support and maintenance. Drupal and WordPress are highly-evolved Open Source Software (OSS) projects. And like any dynamic OSS, in order to get the most from it we have to stay on top of patches and modules that are part of the ecosystem, part and parcel to website maintenance and support services.

Take a look at the Drupal project site, the release window for the platform adheres to time windows similar to those of agile. Bug fixes for the two most recent major versions are slated for the first Wednesday of every month. Security releases for these two versions are targeted for the third Wednesday of every month.  This is in addition to a schedule of patches, minor releases, and critical end-of-life (EOL) notices that come out on a fairly consistent basis.

With Drupal and WordPress you will come to expect very rapid development and the ability to stay competitive and scalable compared to practically any other web site. So in a Drupal or WordPress context, non-Aagile software development on the support side is really a losing proposition. If we choose a website support model stuck in previous generations, we fail to harness the power of Open Source.