Stuart Strickland (Empired)
Many projects suit an agile approach, while others are perfect candidates for the waterfall model.
When Stuart Strickland came to co-found Perth-based IT consulting firm, Conducive, in 2006, his software development background was predominantly steeped the conventional waterfall methodology.
In short, the model is a sequential software design process, based on a steady downward flow through the phases of conception, initiation, analysis, design, construction, testing, production and implementation along with maintenance.
Through the influence of his Conducive co-founders however, Strickland learned that the relatively newer agile approach to software development could offer a different, and crucially more effective, way of doing things - depending on the nature of the job.
While newer than the waterfall model, the agile development approach is nothing new to the IT industry, which has seen the approach come to dominate large chunks of the market.
Its iterative, team-based approach to creating software has won over many fans.
And for good reason; it can enable the incremental delivery of features which, in turn can facilitate a greater speed to market.
It also offers an enormous amount of flexibility for customers to pick and choose features as a software project takes shape.
Conversely, the waterfall approach dictates a linear approach to the creation of digital solutions and platforms typically marked several stages, each of which needs to be completed before the next can begin.
Both development models lend themselves well to different sorts of projects.
The waterfall approach, for example, can suit large integration projects, with multiple systems that need to talk to each other.
“There’s no point trying to do that in an agile fashion, because you need that specified up-front, very clearly about what the system is going to send and what it is going to receive,” Strickland said.
Equally, the agile technique can work well for a whole range of projects, including software involving websites, reports, screens, and scenarios where multiple iterations of a solution will help to drive a solution towards its intended goals in a short or limited timeframe.
The company that Strickland co-founded over a decade ago adopted the agile approach upon its inception.
It is this methodology he and his team has since rolled out through Australian Securities Exchange (ASX)-listed IT services provider, Empired, after it acquired Conducive for almost $8 million in 2012.
As a local independent software vendor, Empired approaches many, if not all, of its software development projects from an agile perspective – only adopting a waterfall approach when required.
“I’ve spent 20-odd years doing projects in all various manners, such as agile and waterfall, and I find agile gives a far better result,” said Strickland who now acts as general manager of Western Australia, at Empired.
“The user gets something at the end, which is very closely aligned to their business need.”
Whether it takes an agile approach or not, Empired builds much of its software off the back of some of the industry’s most popular platforms such as Java, and Microsoft’s .NET framework, while also employing integration tools, such as Red Hat’s JBoss middleware.
Using these tools, Empired’s 300-strong customer software development team creates new solutions for clients from scratch.
At the same time, the company sometimes opts to resell existing solutions to clients, depending on the requirements of the job and the budget.
An agile process
While the agile approach to development comes with its own set of challenges, Empired implements a tailored process to ensure everything flows smoothly.
Initially, the team will sit down and do a scoping workshop with the client, producing a set of user stories – short descriptions of features as described from the perspective of the client – and also drawing up the high level architecture.
Upon conclusion of the work, which might take anything from a week to months, depending on the size of the system, the company will have the high-level architecture and the user stories complete.
“From that we can do a very accurate estimation, and we’re quite happy at that stage to fix the price and delivery of that piece of work,” Strickland said.
Then come the sprints – a set period of time within which a specific piece of work has to be done.
“We go through and we do that delivery in an agile fashion,” he said. “Even though it’s a fixed price piece of work, we’ll sit down with the user at the start of each sprint, and we’ll review the user stories we can deliver in that sprint, and we’ll let them decide which ones get delivered.”
Although the price is generally fixed by this stage, clients can swap in any new user stories, as long as they take one out which is approximately the same size.
The early, quick delivery of iterations under the agile model gives Strickland and his team the wiggle room to alter elements of the project on the fly.
“Through the agile methodology we try to deliver very early and very quickly to the client,” he added. “They’ll start seeing the system at the end of four weeks. And every four weeks we’ll aim to deliver that system.
“As they [clients] are seeing it, they’ll then start to realise what they really want.”
As long as the minimal viable product elements are being delivered, a lot finessing can be carries out, even in the early stages.
Battling the cons
The benefits of the agile approach are commonly understood; it’s flexible, fast, and innovative. But there are drawbacks too, many of which can be alleviate with good project management.
“Certainly, there’s always a challenge around technology and architecture risk,” Strickland said. “One thing with working in that [agile] fashion and not knowing everything up front is that it is difficult to design how the overall system needs to behave.
“We solve that in the first sprint by tackling all the more difficult and technically challenging requirements, so that any architectural issues emerge early, and we’ve got the rest of the project to, if necessary, make changes.
“And we’re not locking ourselves into a technology that isn’t fit for purpose.”
For Strickland, making sure a project sees the development of the minimum viable product is paramount, providing the end-user with something usable, within the bounds of the fixed, agreed-upon cost.
However, not all projects go quite this smoothly.
“The biggest failing of many agile projects is that go on forever at the end,” Strickland added. “There’s a very strict methodology to running an agile project correctly, and many companies just see agile as a way of not having a project manager, and not having to govern a project.
“There is nowhere to hide in agile, but during a big waterfall project, nobody’s checking up on you.”
This article originally appeared in the November issue of ARN magazine - to subscribe, please click here
