Agile methodology has been around for a while and has proven its worth in various situations. That being said, there have been instances in which it hasn’t been as successful. This has lead to people questioning the suitability of agile and more specifically, its manifesto. As a result, a call has gone out to revise the values and principles on which agile is based.
The Agile methodology refers to a software development process in which collaboration, cross-functional teams and self-organization play key roles. Also included in the process are things like adaptive planning, continuous improvement, early delivery and rapid response to change. In simple terms software is created through breaking a project down into phases and upon completion of each phase, working software is passed along to the client. Add in constant communication with the client and high quality development practices and you’re good to go.
The particular draw to agile development stems from things like superior ROI (Return on Investment), a reduction in potential risks due to constant delivery of working software and constant inspection, an increase in productivity, a sustainable development environment, self-directed work environment and a software development approach that takes the uniqueness of every project into consideration.
When the Agile Manifesto was written it sought to bring meaning to the agile methodology through shared ideas, values, objectives and motivations. The<a href=”http://agilemanifesto.org/principles.html”>12 principles</a>that resulted do exactly that as well as highlighting standards that every instance of agile should encompass and accomplish.
If the manifesto specifies certain values and principles shouldn’t that be the accepted mode?
Not for a large number of developers. There are those who have used Agile and find it doesn’t work for them and then there are those who want to revise the manifesto so agile does work for them. For the most part, the issue involves the complaint that the manifesto details unrealistic viewpoints and how it’s next to impossible to adhere to them. Basically it’s the idea that things need to be updated so they apply to the present.
For one there’s the example of businesses shipping their software needs overseas which makes it nearly impossible to follow agile methodology.
Other instance include cases where people claim to be following Agile, but they aren’t really. In this case, there’s the claim that the core values of Agile have been forgotten.
And then there are cases where people want better specifications of skill, discipline, etc.
While there are some valid points in the aforementioned scenarios, there are others that simply don’t make sense where agile is concerned. For instance, in the case of overseas development work, it’s possible to send templates and requirements, but the practice falls outside the scope of agile. After all key points of agile are collaboration between client and developer on a daily basis and face to face communication. Changing the manifesto to allow for such an situation isn’t very agile.
Moreover, it’s entirely possible that some find agile difficult to use in its current state because they aren’t taking the methodology far enough or that they’re taking it to far. Essentially this means that they might be putting too much emphasis on certain things and not enough on others.
The examples aside, it’s important to note that changing the manifesto means changing the very definition of agile. As is, the principles of Agile work because they support each other.
For now, there are no present or future plans to revise the manifesto. Honestly, the debate has been going for years now and there hasn’t been any change. That being said, there’s certainly enough a push to see it happen. Given that information, one has to wonder if a revision will ever truly come to pass.