It seems everyone is into Agile these days, InnoVet Health included.
As its name suggests, Agile is the ability to create and respond to change, moving quickly and easily. It’s an umbrella term used for a set of frameworks and practices created for an adaptive style of software development.
After a lot of frustration with other methodologies, a group of software engineers documented a framework that is now known as the Agile Manifesto. This framework is revolutionary to software development because it allows projects to adapt and respond to requirement changes quickly so project management teams can change course and continue on with their project in a timely manner.
But if we go back in time, before the Agile Manifesto was on the minds of savvy software engineers, almost all software development was developed by applying a methodology we now know as “Waterfall.”
The problems that arose when applying the Waterfall methodology mostly had to do with the extensive consumption of time required for the end-to-end software development process.
For example...
When using Waterfall, the software development life cycle is sequential – meaning each phase of the cycle cannot begin until the previous phase has been completed. So, if there is an issue in one of the previous phases, the team must return to that phase and correct the issue before continuing.
Talk about delays in project deadlines!
Waterfall also required a very lengthy “analysis phase.” The Waterfall methodology typically starts out with an analysis phase where the behavior of the software is documented with incredible detail. This detailed documentation is called a “specification” and software engineers relied on it to determine what to build and how to build it.
The act of building a specification document was very time consuming, and the entire software specification would need to be completely written out before any development could begin.
For complex software projects, this could be very time-consuming.
One of the greatest weaknesses of the Waterfall approach is that it can take a very long time before feedback for project approval is received on the assumptions made within the detailed specification.
This means, even after a lengthy analysis phase (Problem #2), the entire project could be squashed in an instant because of a denial in stakeholder approval, market rejection, or project feasibility.
Meaning, after extensive work was already completed on the project, the product could ultimately be deemed not fit for the market or even worse, simply wasn’t what the client originally wanted.
This whole process forced companies to hemorrhage large sums of money and engineering time because many of these products never have, and never will, achieve final approval.
Can you feel the pain of technology companies worldwide who used this methodology?
However, these are the exact problems Agile sought to alleviate.
Part of the Agile manifesto’s key ideas is surrounding the continuous delivery of valuable software at the shortest interval possible. The result is that Agile teams can develop software in an iterative fashion, meaning the design process of a product or application is improved upon continuously through repeatedly reviewing and testing the product.
This enables the software development process to adapt quickly to requirement changes, market assumptions, and the need to pivot.
For this reason, the Agile framework for software development allows software engineers to see better results faster, with significantly less cost to the company.
Because of this continuous delivery of software, we see a solution from using Agile to Problems #1 and #2 of Waterfall.
Agile methodology greatly reduces the cycle time between the “analysis phase” and the project feedback required for market approval (Problem #3 of Waterfall).
The reason for this reduction in time is Agile advocates for small, generalist teams and face-to-face communication over written specifications.
There is a book written on this titled The Mythical Man Month that explains why you cannot throw bodies at a software project and expect it to run efficiently. The reason for this is because with every new person comes an increase in complexity around communications.
So instead of large, unwieldy, and siloed teams, Agile champions smaller generalist teams so that there is less communication complexity.
The short cycle time to receive feedback allows clients to quickly test their assumptions and adapt to the rapidly evolving needs of stakeholders.
However, there are some cons to the Agile methodology.
Namely, it has been widely reported that Agile is not appropriate for very large projects. According to Agile Approaches on Large Projects in Large Organizations by Brian Hobbs and Yvan Petit, there is an, “’agile sweet spot’ which consists of small collocated teams working on small, non-critical, green field, in-house software projects with stable architectures and simple governance rules.”
Many large organizations who have taken the same framework from using Agile at a team level and applied them to an enterprise level are still at a stage of experimental implementation. Many with paradoxical results, mostly being negative.
However, could Agile be suitable for large projects? We believe it depends.
As for InnoVet Health, we prefer using the Agile methodology because it works well for rapid development and innovation. When dealing with product-based solutions, the Agile framework creates an environment that encourages an experimental and innovative approach to software delivery that we thrive upon.
By: Daniel Fredriksen (Data Scientist at InnoVet Health)
InnoVet Health is an IT consultant company specializing in AI and business intelligence, digital services, and health interoperability founded by MIT-alumni & informatics experts. Learn more about us on our website or reach out on LinkedIn.
Driving modernization and improving healthcare for our nation's Veterans.