Just saying the word ‘agile’ conjures up mental imagery of gymnasts, rock climbers and other nimble athletes. That’s why a (relatively) new way of handling both software development and deployment is described this way. Agile methodology in software development and deployment is fast, flexible, and highly effective. It enables teams to ‘float like a butterfly and sting like a bee’, in the words of the lithe boxer Muhammad Ali.

Since April this year, Soft Tech has taken an ‘agile-only-approach‘ to new software implementations. I’m pleased to share with you that this has resulted in great success, with nothing short of a phenomenal impact on delivery and efficiency. Let’s see why, starting with a quick overview of what the agile methodology is.

Conceptually, agile methodology is easily understood. It is a collaborative effort of self-organizing and cross-functional teams which includes customers. Agile incorporates adaptive planning, evolutionary development, early delivery, and continual improvement. It also encourages flexible responses to change.

What this means as applied in Soft Tech software implementation, is a far more rapid ‘time to minimal viable product’. In other words, instead of signing a contract, going away for 12 weeks or more and coming back to a ‘mostly complete’ software implementation (which may or may not accurately match your requirements… a lot can change in 4 months), you’ll start seeing delivery in as little as two weeks.

And then more delivery in another two weeks. And so on.

This is quite a different way of delivering software and, quite frankly, it works far better.

Agile Methodology

Agile Scrum Process

Part of the reason is that software implementations are notoriously tricky, with multiple moving parts, integrations, workarounds, unexpected realities, changing requirements, and more. This makes it exceedingly difficult to nail the exact requirements at the initial point of signing the contract. There are just too many ‘unknown unknowns’ which inevitably turn up as the deployment team gets to work.

When there are large gaps between getting started and project milestones, there’s every chance of one or both of two things happening. One is the project team straying from its mandate in dealing with those ‘unknown unknowns’. The other is that the business itself might find its requirements changing, or needing new functionality not specified, or even ditching specified functionality because of a market or some other change.

The CIO of a large New Zealand bank once described the traditional way of implementing software as ‘trying to walk across a football field with a blindfold on. Sure, there’s a chance you might find touchdown, but wandering off randomly is far more likely’. With agile, you effectively lift the blindfold every ten yards, recalibrate, get heads down again, get some deliverable work done, and lift the blindfold again by re-engaging with the customer.

Now, as you might imagine, agile delivery does have changed requirements, both on the software deployment team and – crucially – for the customer too. That’s why I’ve got that in bold italics, above.

Customers who haven’t participated in agile delivery are often quite surprised at the amount of overhead it requires. Cross-functional teams and regular report-backs are part of the process, so instead of being left to get on with ‘business as usual’ for 12 or more weeks, you’ll be fully engaged with the delivery process.

This is entirely necessary, as being close to the action means staying well on track. You are, in a sense, the football coach working with the players to see them safely across the field and into touchdown.

But the additional effort is absolutely worth it. By the conclusion of an agile delivery, you have software that you understand more fully, which is accurately configured to your requirements, and entirely fit for purpose. Given the close collaboration, your users are also ready to go – training and learning on the system has taken place throughout their involvement in the project, so it isn’t a sudden change to something brand new.

I’ll be discussing a few more aspects of agile methodology delivery in the coming weeks. But for now, if you have any questions or comments, please do get in touch.


Read the next article in this series here.