Agile should not result in Painware by Moira Ashleigh

Posted on October 14, 2015 at 6:00 PM

Blood Moon Lunar Eclipse, Woburn, MA

Agile is the new catch phrase and somewhat new technique for software development. Having worked on Agile teams I can see the benefits. In my experience the Agile process, when managed well, truly builds a tighter team and captures problems earlier in the development cycle. I think Agile has succeeded remarkably well even with the resistance that it has experienced.

Where I think the next focus should be, for Agile development, is how does Agile rollout affect the end user or client.

Some companies get it right, their Agile releases are virtually invisible to the end user. All that might be noticed is that the product is faster or has a few more benefits. This is most likely the result of great pre-planning for the story and sprint cycles.

Yet several large companies/organizations seem to have taken another route and put more of the onus for for updating on the end user. These are the tools that I call Painware.

One company has moved their industry standard set of tools to a subscription model. The user never really owns the software and constantly rents the use of it. Sort of like getting a magazine that you can't do your job without. Leaving this purchase model aside, the actual day-to-day use of the tools involve continual updates that need to be downloaded and installed. Sometimes this happens more than once in a week. Even more onerous, some of the tools fail to update correctly but they are never removed from the queue. Each time a user opens the software they get a update warning, sometimes it is useful and sometimes quite frustrating. The user can choose not to update right away, but there is not an simple way to see if the update is critical or just nice to have. Painware.

There is a popular content management system (CMS) that has a similar release pacing. The developers are continually working to improve the core product. In part, I assume, to add cool new features, the other part is to stay ahead of the many crackers. I truly admire the work that goes into this undertaking at all levels.

Within this CMS, there are a multitude of look and feel add-ons plus another hoard of additional feature modules, that are not part of the core CMS. Every time the core CMS updates, one at a time these additional add-ons and modules need to update as well. Plus these add-ons often have additional updates between the core CMS updates.

None of this updating is invisible. The CMS administrator needs to go in and manually tell the updates to process, often backing up all the files before a large update. Note: there are other add-on tools with which this updating process can be managed, they also need regular updating. Any administrator, responsible to clients, needs to check that the updates are installed properly and work as expected.

The upshot is that every couple days your notification tool fires off a warning that something needs to be updated. And worse if your add-ons do not get updated, they begin to conflict with other add-ons and you have to trouble shoot the whole system one add-on at a time. If there is a serious conflict between add-ons, the CMS administrator has to go out and find a new feature tool to do the task. Painware.

I am sure there are other examples out there that I am not aware of, but these are the two that I deal with on a day-to-day basis in my job.

My final analysis is that Agile is a great process for the development team, and I strongly support using it. But it would make good sense in the planning process to consider the how the end user is affected by the Agile release process. Otherwise you end up in a reactive system.

UI Mantra: Agile should not result in Painware.

Twitter Feed