Agile, Continuous Delivery, Devops, Iterative and Incremental development are the buzzwords in today’s day and age of software development. If you happen to be an agilist, then you know that it wasn’t an easy time before the birth of agile. In fact, agile has come a long way and has in fact paved the way for creating software that we use today.
In this article we will explore the reasons that led to the birth of Agile and how it has led to the formation of the frameworks that we are so familiar with today.
During the 80’s and 90’s, the waterfall method was popularly used for civil and mechanical engineering projects. The waterfall model is perfect if your requirements are never going to change which makes sense as their requirements and the design remain the same for years. The same ideology was used for software development. But it never yielded the desired results.
Depending on the complexity of the solution, it would almost take three years or more, from an idea to be implemented into a working software that can be delivered to the customer. And during this time, business needs were never fully met which would lead most of the projects to get cancelled. And if there was a change in requirements that needed to be made, there was no room for accommodating this change. Since the product would take so long to make, it would eventually lose its value in the market. Although, theoretically in the waterfall model, you can shift back to the previous state. But in reality due to the scope and budget constraints, it was nearly impossible to do so.
The element of finality in the waterfall model, was one of the reasons that made it a very heavy framework. When it comes to developing software, you have to realize that developing software is different as it can never be absolute. There needs to be a lightweight method that allows adaptability and room for continuous change. There has to be a responsiveness and swiftness to any changing requirements. And lastly, it needs to be quick. It needs to be relevant with the times.
For creating software, you have to deal with a lot of ambiguities, misunderstandings and miscommunications from the business owner in order to fully translate the requirements. It takes time to clearly define the scope so that what you make is precise and to the point. You need to involve the business owners and stakeholders in such a way that you get regular feedback from them. So that you know that you are in some way or fully implementing what is needed. You need to have small processes. All of these were soon to become traits of Agile.
The Agile Manifesto was made in 2001 with a set of principles and beliefs of agile. It was made as a solution to the problems that were being faced using the Waterfall Model.
Although the term “Agile” came later on, the principles and its features were set. This included having shorter lead times, lighter processes, open communication, continuous learning and adapting to change as you go along.
These became the set of beliefs that were to be followed. For any reason if the development team was not satisfied or the customer was not content with the software, the development team can still manage to adjust to the changes that were needed.The software was released earlier with better quality and getting quick feedback helped make a product which best fit the requirements.
What is an Agile Framework and Why Need it?
An Agile Framework is a set of practices or guidelines for effectively developing software. They are based upon the principles set in the Agile Manifesto. The absolute reason why you need an Agile Framework is to implement the principles of Agile in such a way that it easily helps in coordinating and synchronizing the work of the members of teams.
The first popular and widely used agile framework was Scrum. During the 1990’s, Scrum was gaining repute for developing complex products in short iterations with small teams who were self managing. It was easily understood and allowed the flexibility to adapt to changing requirements.
Since the characteristics of Scrum resonated with those of Agile, it became an integral framework of Agile. Similarly, Kanban and Extreme Programming, which were also emerging as developing in timeboxed iterations and increments at the same time, became solidified as a part of Agile. With time, more agile frameworks were added under its shadow. But Scrum still reigned all over. It is so popular that it still confuses some that Scrum is better than Agile which in fact is false.
Fast forward to today, there is an increased competition amongst companies, heightened market demands and there is always a need for faster time to delivery. In order to meet these demands, the size of the software companies also grew and had hundreds or even thousands of employees, depending on the size of their project.
Knowing that the ideal size of a scrum team ranges from 6-12 participants, managing a huge workforce can become a problem. And at the same time maintaining delivery, engagement, and quality can become a daunting task.
An agile framework like Scrum has to be scaled. Processes and newer roles have to be defined so that they aid in easier management. So that it can match your increasing business needs, to smoothly coordinate all of the team members on the same page. In a way, this is an example of how agile is constantly evolving. The birth of having agile frameworks that can be scaled is an example of how you alter to changing and increasing needs.
Today, popular frameworks like Scaled Agile Framework, Disciplined Agile Delivery, LESS or Nexus dominate the software development industry. Scrum happens to be at the root of all these frameworks. They are suitable for companies that create complex products and have multiple teams to work with. The effective utilization of these frameworks helps you deal with growing market needs and increased competition.
But how do you know which framework works best for you? There really isn’t one best framework. It really depends on how your business operates and what suits your requirements.
Agile is a mindset. Embracing and understanding its essence is extremely vital. It promotes equality amongst the teams. It tears down the silos and brings everyone together on the same page. It eradicates the hierarchy amongst the teams. Applying what suits your requirements isn’t enough. Agile has to be implemented wholly and entirely. Although this is the hardest thing to possess but having this mindset is the cornerstone for transitioning to agile.
Digital boards to manage dependencies, multiple teams and program increments for scaling agile initiatives. Kendis works on top of JIRA and other agile tools, your teams can keep on working with their existing JIRA boards and program level and above is planned and managed at Kendis.