The birth of the Agile software development movement can be traced back to February 2001. 17 experts (including legendary figures like Martin Fowler and Robert C. Martin) met at a ski lodge to discuss the future of software development. Over the course of that weekend, they produced what we now call the “Agile Manifesto”.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto: 22 Years Later
The manifesto is now 22 years old. Does it still hold up? Initially, I would argue yes, however you must remember that this Manifesto was written when the waterfall methodology was king and the amount of discoveries and new tools available today have completely changed the game. These developers met because they collectively realized that the status quo of development was not working. In many ways the world of 2023 is vastly different than 2001, in other ways it feels like nothing has changed. Today, we are going to be dissecting each point of this manifesto, to see how these core beliefs apply to real life software development over 20 years after its establishment.
Individuals and Interactions Over Processes and Tools
Note that the phrases, “sprint, burn-down chart, backlog, velocity, and stand-up,” appear nowhere in the manifesto. The heart of Agile focuses on people and how they interact. Processes and tools are important, but they should support the people and interactions, not inhibit them. This still rings true, in short, even the best digital tool on the market can only get a team so far if they do not have a well-planned operating procedure in place for collaboration and achieving goals as a unit.
Working Software Over Comprehensive Documentation
This line is often misunderstood. Agile is not about doing away with documentation. The primary purpose of a developer is to build working (serving the customer’s needs) software, documentation does not have value of its own. It is only valuable when it aids developers inbuilding software and aids their customers in using it. While we understand nowadays that having quality data documentation is a pillar to successful software development, it is still only a piece of the puzzle, and I would still agree that developing a software to serve the desired need of a client or customer holds more value than the documentation itself.
Customer Collaboration Over Contract Negotiation
The customer should remain engaged with the developers throughout the software development lifecycle, not just the beginning and end. It also addresses the problem of “throwing it over the fence”. Where a customer dictates the requirements and then disappears. It is important to keep the customer fully informed on the decisions made and for what reason to ensure each action aligns with accomplishing the desired goal. The conclusion here is simple, most professionals would agree that communication between two parties will always be the most fool proof way to ensure everyone is aware of advancements in a project and prevent having to circle back and explain past decisions.
Responding to Change Over Following a Plan
Outside of the most trivial applications, you will discover things as you develop. Some things I’ve learned in the middle of projects: the database that was supposed to have quality data is actually unusable, a configuration quirk in the data source prevents us from using Fivetran and we have to quickly switch to Azure Data Factory, the size of the data is way bigger than we thought and now Power BI is taking forever to refresh. Essentially, we can never be fully prepared for what we may encounter and Agile accepts the fact that deviations from ‘the plan’ are inevitable. Fighting change will always be a losing battle.
Conclusion
Too many people become wrapped up in the rituals of modern Agile: sprints, stand-ups, burndown charts, etc. These are merely tools designed to aid developers, and if these tools are not working for your team then it is perfectly Agile to not use them. It is crucial to take a step back and revisit the first principles of the Agile movement to understand what they really mean for your team of software developers and how to use them to your advantage.
The Agile Manifesto was curated to resolve present day issues and promote the future success of software development. Now 22 years later I would argue that, with proper understanding and application, the values of this manifesto hold true as crucial to the success of any software development team.
To further discuss the Agile Manifesto and understand how these beliefs can support your organization, Contact Us to speak with one of our experts!
