Agile? — Accelerate? — Putting Things into Perspective…

Agile software development is the hype in IT companies, has been for a couple of years. Based on a number of different project management systems, ‘Agile’ is the idea of being more flexible and fast in producing development results. But slowing down these days can be the best option after all!
Agile methods could be adapted saving resources of all concerned and improve quality even more.

Before Agile There Was…

The previous methods used in such environments such as ‘waterfall’ or ‘management-by-objectives’ seemed at one time to be unable to reflect the market’s speed of changing or offering new or just more powerful hardware. And at the bottom also is the age-old worry of being too slow in the market that has been defined not only as a competitive place, but where being the first in a new market segment can be crucial for a company’s overall success.

Upgrade Costs…

But is it? Always?
Let’s look a little closer:
Once a product has been established, in software you not only need new customers. You need existing ones to stay.
Even in the private or small business sector the costs of a software acquisition are not calculated by initial prices alone.
Included support options, upgrade cycles and necessary maintenance on the customer’s site and with customer resources are essential.

If a software is pretty straightforward and not very difficult to learn or use, frequent updates are no big deal. Although even these may cost ‘extra’, depending on hardware and software requirements and dependencies, as well as personnel involved.

Cost Considerations

More complex systems and setups as well as hardware and software environments and surroundings need a lot more considerations to be taken into account:

• Are there projects being conducted with that software that should not be interrupted?
• Are there downtimes to be expected that would result in loss of business?
• Are there complex upgrading procedures to be executed that not only need the setup of developing and staging systems but also additional personnel that maintains and monitors those?
• Are recent upgrades crucial for the overall function, contain vital improvements that will increase performance or usability? Or can they be skipped perhaps in favour of saving the above..?

Especially the last point in my opinion is the most decisive one these days: since ‘Agile’ indeed has become a hype, any and almost all software is updated practically at a daily rate.
Any operating system you can think of as well as the installed applications see updates or upgrades often on a weekly basis, these days.
And the risk is always there, for an upgrade being unstable, containing new bugs besides the ones that were fixed and involving higher costs in rectifying or migrating existing data.

Simplify Life

Personally, I sometimes would like to scream at my screen, when yet another update tells me: ‘they are agile again…’!

I am not talking about security or safety updates, or patches necessary to ensure performance or improving faulty behaviour!

I am talking about endless streams of apparently useless or sometimes even annoying upgrades and changes ‘no matter what’, just so an upgrade is being made…

And since costs in enterprise environments, where sensitive data more often than not is involved, could sky-rocket easily, let’s think again:
Do we really need to be faster and faster and faster every day? Even let customers become irritated…?
Or could slowing down be the solution, really, to make lives less fraught with mishaps to software and workflows again, and fix bugs in good time and smaller patches.

Take One Step at a Time — Slow Down — Save Resources

Too frequent upgrades and frequent additional costs is not a solution but yet another issue…

So, a few steps as a result from the above could be:

• Change requests show the way, regarding complexity and effort needed when and if a new release can be bundled.
• Support and the sales’ as well as consulting’s customer contacts also can provide a good idea, how often releases, major or minor, make sense.
• Making improvements part of patches can be a comparatively quick and easy way to engage customers, let them see the ‘light’ once more, and keeping the big picture for a major release in mind — perhaps once a year.
• Resources saved can be the ones of the customer as well as the vendor. And the next release will be the best ever!
• A half-year cycle can make sense now and again. But ‘release for release’s sake’ does not.
• Let them know about you and your fantastic product all the other ways our digital and ‘social’ world provide! With dignity and the joy you feel about the good stuff that’s to be released — a little later!

Let’s slow down!