When it comes to writing about the evolution of agile or its history, I can only provide you with factual data that already exists. There are numerous blogs and articles on the history of agile, and how it has progressed from Lean to Agile and now to much more refined methods in the present day. As I read through the developmental phases of each method, I could relate to my own experience. My academic projects were all developed using a waterfall model, and although there were other methodologies such as spiral, risk and prototype models, they were all confined to textbooks. For us, the software development life cycle was synonymous with the waterfall model.
I remember my teachers guiding us to document all the requirements, draw an ER diagram, manually draw the database tables on paper, create all these database tables at the backend, design an application interface mostly using Visual Basic as a front-end, connect the backend to front-end, write the code, test it and implement it. If we followed these steps, the project would be successful.
Gradually, when I moved to Henkel Adhesives, I was given the big task of documenting system requirements specifications, which we called ‘spec’ at that time. There were two kinds of documentation, one for business requirement specs and the other for technical requirement specs. Technical experts needed to know the ins and outs of these requirements, as one small mistake could cause the whole project to fail. Going back to previous phases and redoing them was a big hassle then.
Projects dragged on for what felt like an eternity, with each phase requiring countless hours of documentation and meticulous planning. When we presented a module or an end product to a user, there was a chance that the client would say it was not what they had asked for, or that another company was already doing it, and could we do the same. Time and money were the biggest constraints then and now, but back then they were the major constraints. Building documents, tools, training, and everything else was cost-oriented. The number of lines of code, the number of people, resources, wastage, learning and training, implementation, and maintenance were all part of cost estimation.
In the past, there was no concept of small teams, until the concept of startups emerged.
Today, I work in a small team where I communicate and collaborate with all my team members on a daily basis. We are all placed remotely, yet any problem can be resolved within a matter of hours or a day. We develop projects in shorter timelines, in a matter of days and months. We involve stakeholders at every phase of the project, asking them what they need and building the tools accordingly. We break down those rigid structures and try to put them back together to work.
From the rigid principles of traditional methods to these four magical agile principles that were born in 2001, with a group of people who thought about people first, tools next, working software over documentation, customer collaboration, and responding to change, the journey of agile is magical to me.
Evolution of Agile from Lean to Present Day
Unleashing The Agile Manifesto : Behind the Four Values that Revolutionized Software Development
The Waterfall model was not a failure. It worked successfully for many years, and its revolutionary impact is undeniable. The model’s clear process aimed to deliver a final product that met the requirements and quality standards. However, its downfall was caused by another revolution: the internet. Web applications require flexibility, and the Waterfall model’s rigid approach does not fit this requirement. Its disciplined and inflexible nature is what ultimately led to the downfall of the Waterfall model.
The core principles of the Agile Manifesto were developed through the collaboration of a group of experienced software developers who were frustrated with the inefficiencies and limitations of traditional software development methods. They came together in February 2001 to discuss and agree on a set of guiding principles for Agile development.
During this meeting, the group discussed their shared experiences of what worked well and what did not work well in software development projects. They identified four values that they believed were crucial to the success of any Agile project. These values were:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The group believed that these values would enable software development teams to be more responsive to changing requirements, to deliver higher-quality software, and to have better communication and collaboration with their customers.
The group also developed twelve principles that were aligned with these values. These principles were intended to guide Agile teams in the practical application of the Agile Manifesto. The principles emphasized the importance of working in short iterations, delivering working software early and often, encouraging collaboration and communication, and allowing teams to self-organize and make decisions.
What do the four key values convey?
Effective communication and collaboration between team members and stakeholders is key to the success of any project.
1. Individuals and interactions over processes and tools:
This value emphasizes the importance of prioritizing human interactions over relying solely on tools and processes.
Do not discount the importance of documentation, but rather recognize that delivering a working solution is what ultimately brings value to the customer.
2. Working software over comprehensive documentation:
This value advocates for the delivery of working software as the primary measure of progress
Effective collaboration with customers helps teams to better understand their needs, resulting in a better end-product.
3. Customer collaboration over contract negotiation:
This value highlights the importance of involving customers and stakeholders in the development process.
A plan may not always be feasible in the face of constantly evolving market demands and changing customer needs.
4. Responding to change over following a plan:
This value emphasizes the importance of being able to adapt to changing requirements throughout the project
Wrapping Up all I want to say is, as technology continues to advance, it’s important to adopt an open mindset that values collaboration and innovation. Rather than relying on rigid structures and power imbalances, organizations should prioritize giving everyone a voice and the freedom to contribute. This approach can lead to more efficient and timely outcomes, which is essential in today’s fast-paced work environment. Ultimately, respecting and utilizing time wisely is critical to success, and embracing a culture of continuous improvement is key to staying competitive in an ever-evolving technological landscape.
