There seems to be numerous growth factors when implementing agile development to accomplishing goals that are dependent on scaling factors, expertise, feedback, and continuous delivery.The lack a foresight in Waterfall methodologies and what can be accomplished with Waterfall style development, creates encouragement to move away from this type of development. Why? Waterfall, is what it describes, each step in the process is well calculated beforehand with the best intentions, cascading each step after another. Is it fair to say that Agile Software development has needs too?
Here is brief description, Project A has features like an user can read a library catalog of their favorite books, Project B has features that are the same though each part of this feature is set in stone before any code is written. As time goes on Project B adds this feature by the expected deadline, project fails to meet the deadline because more information is needed to finish before moving to the next step (such as testing), which includes testing for all the features at the very end. This will take a couple months most likely. Project B in this scenario is Waterfall development. Every step that precedes the next is dependent on the success of the features are working before the testing stage. Now in Project A, the feature is coded a bit and then tested right away, sent for feedback by other developers or stakeholders, they give the okay, and the project moves forward. The difference between Project A and Project B, is that Project A is more flexible because the development of the feature is ongoing and as not based on future requirements that might change. Project A in this scenario is Agile Software Development.
The must useful intentions and fail safes to agile development is at the core of it’s purpose, as stated below with continuous delivery from TARGETPROCESS,
Continuous Delivery
Delivery with every single commit reduces feedback loop cycle to a minimum.
This does not make any big difference for end users. But for the team, such extreme conditions create a drastically different development environment, making them improve the quality of code a lot. The company should really get set to stand up to continuous delivery.
Continuous Delivery brings along almost full testing automation: unit tests, functional tests, performance tests, acceptance tests. Delivery should be automated as well. Such an extensive automation requires solid team efforts as well as total process overhaul, from requirements management to marketing. This is about scalability, which makes it even more complicated.
From: https://www.targetprocess.com/articles/the-future-of-agile-software-development/
The idea of continuous delivery seems more instinctive and less deliberate, because as code is being written and then delivered a good response from users or other project stakeholders can be learned more naturally. In other words, every time a build is created or application is ran after adding code, we can see the results almost immediately, this is ingrained into the process of Agile Software Development.
Though Agile has needs too, which means the team would most likely need the project to be flexible and respond to change. This requires an even deeper understanding of application’s architecture that allows the application/project to expand and grow. What is also helpful is that working while being agile, creates fluidness, continuous feedback/learning, positive retrospection, and even some introspection. Even though Agile Software Development has needs too, these needs are less forced, less planned, and leave room for a massive potential of creativity. So the question might be, what do you prefer? A system that you know that cannot not change and tells you “Hey, you can’t change that we already decided to leave it like that!” or one that says “Hey, you found something new, since we expected that to change, let’s do it!
