Agile Development Life Cycle
Traditional SDLC
- Fixed and rigid
- Imposed from the outside on the software lifecycle
- Over-manages and chokes natural software development
Agile SDLC
- Flexible, adaptable, iterative
- Uses CI / CD
- Guides instead of controls software development
Introduction
It may seem surprising to use a term like the Software Development Lifecycle when speaking of Agile Methodologies. The association of the SDLC with the Waterfall Model is ubiquitous and misleading. Agile methodologies avoid using the term because as its traditionally understood, its methodology is the opposite of Agile: It does not use iterations, it is not adaptive or flexible, continuous delivery and feedback is often absent, and it is brittle and it over-manages software development.
Having said that, there is a development lifecycle for software. Software, like any growth oriented process goes through phases. And even when developing software using Agile methodologies, these phases naturally appear. The difference is that these phases appear as an outcome of the iterative process and are not rigid structure imposed from the outside on the development lifecycle.
Kinetic, being a form of Agile recognizes these phases and uses them to adapt the Agile methodologies into very different organizations.
An Agile SDLC
Kinetic
Though the term SDLC is being used, this development lifecycle has nothing in common with the traditional waterfall methodology.
- All phases in the lifecycle are developed iteratively in an integrated environment.
- Every phase in the lifecycle can be implemented by a single team changing its role as the software matures; or by different dedicated teams for each phase of the lifecycle.
- The migration from one phase to another can be automated to reduce lag time between phases.
- The development team can interact with a Custom Resource Manager (CRM) to create and modify resources.
- Swipe the cards from right to left or left to right to see how the phases change when developing a product in an integrated environment.
Conclusion
As the above diagrams indicate, an Agile SDLC is not defined by its phases. Instead the phases are natural progressions which an evolving product goes through as it matures. The diagram also illustrates that the process is like a pipeline or “chain workflow” enterprise integration pattern but – with one notable difference: There are feedback loops within each phase and between each phase of the lifecycle. This pattern can be called an iterative workflow chain.
It is also noteworthy that this process does not emphasize any Agile framework as an approach to developing software. It does not promote SCRUM or Kanban or any other Agile methodology. It does not focus on Gantt Charts, timesheets, timelines or any rules for dictating team behavior. Instead it relies on the essential principles of Agile and teams can choose to adopt whatever framework that best suits them and helps facilitate their development process.
The process is neither dogmatic nor rigid. It uses user stories to define and decompose the product architecture and uses piecemeal growth at every step in its journey. Implicit in this process is the fact that cloud-centric development is not only an integrated environment, but it a highly flexible environment. It allows developers to work remotely or locally or in separate departments, but it also allows the entire organization to access the product in all stages of its development.
Ideate Iterate Innovate
In this model every system artifact from user stories, to database schemas are developed in an integrated development environment in the cloud.
- Discover errors more quickly at every level of the system.
- Develop new methodologies or even system design components earlier in the lifecycle.
- Adapt to new requirements.
Teams can be cross functional teams, remote teams or teams in different departments.
Once a functional component is working, the product migrates to the next phase of the development lifecycle.
The roles and responsibilities of QA in this model, shift towards regression, performance, and scalability testing.
- Regression testing validates existing functionality.
- Performance testing pressures the system.
- Scalability tests verify that the product auto-scales under load and scales to zero when demand decreases.
Teams can be local, remote or in separate departments. The same team that developed the code can be QA testers as well.
Failures in testing are cycled back to development. On success the product moves to the next phase of the development lifecycle.
Operations sets up the methodologies to launch the product into production.
- Fine tune the deployment methodologies and scripts required to deploy the product in production.
- As far as possible, try to simulate the product launch in the on-premise cloud.
- Push the product to production.
- Validate that the product is live and available for general use.
The Ops team is usually a separate team but in cross functional teams, the Ops team may well be integrated into the development team. Cross functional teams composed in this manner are DevOps teams.
Production is the most challenging phase of a products lifecycle
- Clients access the system in many different ways: In bursts, in ad hoc intervals and sometimes in a sustained manner.
- Products that have been tested in these types of scenarios usually perform better than those that have not.
- Production tests a system like nothing else.
- Many of the changes and new products we see today are due to lessons learned in production.