Breaking Down The Agile Manifesto And Understanding It
Fri 17 Jul 2015 00:10
The popularity of Agile frameworks, especially XP and Scrum, is increasing by the day, and more and more organisations are deciding in favour of using these frameworks to execute their projects. Agile proposes many advantages – frequent and reliable product increments, delivering product features having high business values, and above all – delivery of shippable product features even while the development process is underway. However, a major issue with Agile, and all Agile based frameworks is that the framework has to be properly understood and later implemented in the project. Moreover, the implementation should be carried out keeping Agile principles in mind. More than often, businesses fail to benefit from Agile simply because the management has not understood the basic principles behind the framework, or has failed to implement those principles in a proper manner.
Since it was developed in 2001, thousands of individuals including project managers, software professionals, and C level executives have endorsed the Agile manifesto. Hundreds of books and references have been written to discuss what the guide has to say, and how it should be interpreted. The manifesto has drastically changed the way in which organisations and individuals develop software projects. The manifesto packs a lot of punch for its 68 words which have been written by 17 software professionals over a two days meet at a ski resort.
The principles of Agile are stated in the official guide written by Ken Schwaber and Jeff Sutherland. The guide functions as a bible for all Agile groups and Agile professionals. People refer to the guide when in doubt, or when they wish to clarify a particular point during Agile framework implementation. For individuals interested in Agile, it is very important to understand the guide and interpret what it has to say.
We are uncovering better ways of developing software by doing it and helping others doit.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
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.
To start with, the manifesto states “We” i.e. it emphasis that Agile is not a solo endeavour. It involves group activity and people have to collaborate while working, at every level, and at every instant. Development teams, project teams, and organisation have to work jointly as a composite unit, and rely upon each other for completing work.
Here, the guide suggests that Agile does not offer one-size-fits-all type of solutions. Agile cannot be standardized and implemented in a project. People involved with Agile processes have to put in efforts, and strive to seek answers through discussions and collaborations. Answers have to be discovered through experimentation, and the “adapt” and “inspect” principles which are so dear to Agile. It is important to explore new ideas and eliminate those activities which are counterproductive or not effective.
Nobody is perfect. Also, no framework or methodology can be perfect. Instead of concentrating upon perfection, the Agile team ought to concentrate more upon improving the current work process and finding better ways of doing things. Small improvements, gradual but consistent, should be incorporated in the process to make it more efficient and result oriented.
The bottom line – build the software and deliver it. The best way of finding out whether something works or not is to build it and try it out. Failures should be seen as learning lessons, and the team should learn from them. Better methods of working originate from experimentation and the learning process. Rather than spending undue time thinking over whether something will work properly or not, it is better to do it, and learn from the results availed through the implementation.
Agile is all about sharing. People have to share their ideas and experiences with each other. It is not required to make a mistake and learn from it – one can learn from the mistakes made by others. Knowledge should be shared and opinions sought for. Senior team members should try to foster a healthy working environment, and act as mentors for those new to Agile.
The manifesto was envisioned and drafted by 17 seasoned professionals closely involved with various project development methodologies and processes. They represent the core market requirements. Through their experiences and knowledge, the manifesto was designed to target what clients really desire in a project, and how the team should function to satisfy those requirements in the best possible manner by delivering time bound projects having high business values. Agile principles should be taken seriously and valued by all concerned.
Bob Martin has correctly described Agile as “a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work.” The Agile team should primarily focus upon working together while developing the project, and ensure that a productive and healthy working environment prevails at the place of work. If anything – tools, processes, or activity – disrupts the way in which individuals closely work together, serious thoughts and considerations should be given to the issue, and the impediment should be removed without wasting further time.
All Agile frameworks including Scrum focus upon the delivery of working software releases through product increment cycles. The main goal is to deliver product features on a frequent and consistent basis to the client. Resources and time should not be wasted over lengthy documentation. Instead, the team should focus upon delivering the business value to the client. If you have to decide between spending time and efforts over completing the documentation formalities, and in delivering the software, you should opt for the latter. The reason why Agile discourages comprehensive documentation is that people would than require more and more time to read the stuff, analyze what they have understood, and spend even more time wondering what to do next. As a result, they would actually find less time to work upon the project and complete it.
The client is the most important entity in Agile. The process invites stakeholders’ participation and encourages them to become involved with the development process. Agile proposes to deliver high quality working software that meets the actual, and exact, requirements as specified by the client. The team should concentrate more upon collaborating with the customer and delivering the business value, rather than sticking to contract conditions and legal formalities. It means that the team should try to focus upon delivering what the customer really needs rather than honoring and following what the contract says.
Agile is recommended and ideally suited for developing projects prone to changing market conditions. It thrives in situations where the product design is liable to change with time. Changes occurring in the features and functionality associated with the product can be easily incorporated in the process flow, and developed by the team. The unique aspect about Agile is that the changes can be incorporated even when the team is developing the product, and changes can be carried out even late in the product development cycle. The team should be positive towards changes and welcome it. Changes offer an opportunity to deliver something that is even better than what was originally planned.
Agile is a framework. The principles have to be implemented in a workflow or development process, to mold it so it can be more effective. Agile does not suggest you do away with traditional tools and development processes. It merely offers a way of making your existing development process more effective and productive through its principles. The ultimate objective is to deliver a valuable product to the client and foster good relations with him or her.