TL;DR. When talking about the manufacturing of software solutions, we inevitably have to talk about a structured way of working. This is where concepts like Agile or Waterfall come up as guiding lights for developing the particularities of each and every software project. This article explains each approach and proposes a third one as a reasonable mix of the two.
Context
In order to be able to create impactful solutions that aim to make the world a better place, the software development industry makes use of certain development methodologies. These methodologies aim to be a guiding light that everyone must follow until the software solution is successfully developed. Although the general belief is that a complex software solution can be simply “coded” by any trigger happy developer, in reality you need a team of development experts that follow a predictable process. This process is called a “development methodology” and as you’ll soon find out, there are more flavors to it.
What are they?
The most common software development methodologies that have been around for a while are the Waterfall methodology and the Agile methodology.
Between the two, the Waterfall model is the oldest, dating almost 40 years of activity in serving both states and large enterprises for the manufacturing of software. This model sees the development of software solutions as a series of logical phases (SDLC) that a solution must pass through before it reaches maturity. Basically, implementing a software solution according to the Waterfall model means that each development phase strictly depends on the deliverables obtained from completing the previous phase. As these phases can only be executed in a single order, hence the name waterfall demystified.
The new kid around the block is the Agile methodology that awards flexibility in favor of predictability, making it a default choice for startups that want to move fast. This makes it quite different from the Waterfall approach, where every phase is set in stone. Instead, the Agile methodology preaches incremental developments made over a software solution, with just enough information to get started. The base dogma for this methodology can be summed up into the 2001 Agile Manifesto, that proposes principles such as: continuous delivery of valuable software, changing requirements (even late in development), harnessing change for the customer’s competitive advantage, business people and developers working together daily throughout the project.
Since the impact of the methodology on the project is a pretty big deal, let’s go through the main characteristics of each approach:
Having exposed each methodology, now we can better notice the opportunities and (possible) threats of each approach. Of course, a good software development team is aware of these aspects and is able to tackle each along the way.
Why is it relevant?
Choosing one of the two methodologies depends on a larger number of factors such as state of requirements, state of the project, industry of applicability or degree of flexibility to name a few.
Why should this interest you, you may be wondering? So that you can choose the approach that works best for your particular use case.
Education regarding the options available for constructing a software solution fosters:
- effective communication
- realistic expectations
- project success
Pros and Cons of Agile
In terms of pros, Agile emphasizes flexibility, collaboration, and incremental progress. This makes it suitable for organizations that need to move fast and collect user insight that can be converted to specification on the fly. With Agile, you are simply put, being agile. The team develops pieces of the software solution in development iterations called sprints, at the end of which, a functionality is released to the target audience. The information collected from the target audience will serve as the scope of development for the next development sprint, without being rigid. This approach comes in hand when experimenting with a product, when you want to test and see how people react to a certain product.
The Agile mindset goes something like this: “I am going to build something small that can be extended or changed in the next development iteration.”
The disadvantage with Agile happens when the budget gets out of control due to continuous introduction of features. As Agile does not have a roadmap set in stone, it’s easy to get carried away by what you may think is cool and to keep developing features on top of features. Without a roadmap, this can be a recipe for disaster.
Pros and Cons of Waterfall
The Waterfall methodology has the advantage of being pretty predictable in terms of costs and time. This methodology is your go-to strategy for when you obtain state funding or when you have a strict corporate budget for building a software solution for which you already know everything there is to know upfront.
The Waterfall mindset goes something like this: “I am going to build this entire solution to spec, and if I want changes, I will have to manage them as a separate project”.
The disadvantage with Waterfall is that it’s not meant for experimenting. Once a phase has passed, the deliverables from that phase cannot change.
Our custom approach
Our approach focuses on taking the best out of both worlds and merging them into a straightforward way of working that progresses the solution from 0 to 1 in a Waterfall fashion and then from 1 to n in a purely Agile way.
For projects started from scratch (0 to 1), we make use of the 123MVP development pipeline as it focuses on bringing up a software solution in 3 simple phases:
Phase 1 → Prototyping, where by using specifications, a functional prototype is created that serves as the scope of the MVP
Phase 2 → Architecting, where specification becomes technical, ensuring that anyone can build the solution to spec
Phase 3 → Development, where the solution is coded into a palpable result
After projects have reached MVP maturity (0 to 1), comes the switch to Agile, where we launch the product, collect feedback, and incrementally build upon it while tailoring it to the audience’s needs (1 to n). We have found this approach to be preferable for projects starting from scratch, as this approach:
- Cements a clear scope for the MVP
- Controls the costs for bringing the MVP to market
- Collects usage data that serves as fuel for future improvements.
An example here would be our Atom project which is currently being scaled across multiple manufacturing plants in different countries. Before it became a “one stop shop” for orchestrating tools around manufacturing plants in multiple countries, it started off as a simple MVP that was tested on a “spare” production line.
It was manufactured from 0 to 1 according to our 123MVP pipeline, having a clear set of specifications and budget. After reaching MVP, it was properly tested in the manufacturing environment for determining various improvements that can be brought on in future updates.
These insights were collected and planned as multiple ‘add-ons’ that would take the solution from 1 to n in a systematic and agile way.
If we were to have a single phrase that describes a mindset for building software solutions, it would go something like this: “Start small with a predictable MVP and evolve it according to usage insight”.
Conclusions
Of course, one learns the big lessons the hard way. So during our maturing as a software company, we also made rookie mistakes, such as not testing a solution on the market in the early stages. But that’s part of the growing process and of becoming more resilient.
For further discussions on this topic, please get in touch with one of our expert consultants at contact@abac.software.
Sources:
https://abac.software/business-agility/
https://abac.software/mvp-a-game-changer/
https://agilemanifesto.org/principles.html
