To anyone or any organization that wish to implement Agile software development, you should first looking at the Manifesto for Agile Software Development found on agilemanifesto.org. The following is pulled straight out of the manifesto…
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
In more detailed is the 12 Principles behind the Agile Manifesto also found on the site that help explain the manifesto.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I never knew this manifesto existing until my instructor from my Agile Power Practices class pointed me to this. As soon as I started reading into it, I could not have agreed with it more. I have been a software developer for over 20 years, ever since I changed my major to computer science from premed back in college. Software development has always been a self taught thing for me. I have taken classes here and there back in college but the majority of what I learned about software development has been from the experiences of working in the industry. And from my experiences, I have been very frustrated with the corporate america way of developing software. I’m referring to the “Waterfall” method of software development where we spend a lot of time going through a series of steps of software development from requirements gathering, to design, to implementation, to deployment, to support, all in an uni-directional flow. I have been told not to write any code until all of the requirements and design have been planned and laid out. When I read the Manifesto for Agile Software Development and its history, I can totally relate and empathize with those people that came up with the manifesto.
According to the history found on agilemanifesto.org/history.html, a group of programmers who were frustrated with software development at that time, got together in the winter of 2001 at a ski lodge in Utah and came up with the Manifesto for Agile Software Development. They were frustrated with software development in that software development has been so “process” driven, it leaves very little room for change and improvement. The group instead, came up with a manifesto that placed software development based on customers, collaboration, rapid development, and continuous improvements. The highest priority is to satisfy the customers, get them involved early and continuously. Software is to be delivered in short burst through working software and empowers the individuals to self organize and improve among themselves. Change is not only allowed, but encouraged.
After years of software development in corporate america, I completely agree with the Agile Software Development Manifesto. I have experienced software development from both side of the spectrum. I have seen how bogged down software development can become if you reply too heavily on processes and documentation. I have seen software development that last months tied up in endless requirement gathering and documentation. By the time the software is developed and finally delivered to the customer, the needs have changed. On the other hand, if you involved the customers closely and continuously with frequent updates and working demos, the customers are a lot more understanding and willing to work with you. Best practices and things that have worked for others, doesn’t necessary work for you. Its fine to make mistakes if you learn from it and continuously improve upon what works for you and your team. And finally, its fine to be reactive and fix the problem quickly rather than spending a lot of time on planning and preventive measures. I’m not saying that having a process or having things planned out in advance is a bad things but it has gotten very bureaucratic with corporate america.
You can’t really understand and appreciate the power of Agile software development until you have looked into its history and understood why the movement came about in the first place. The Agile Software Development Manifesto does a pretty good job of explain this and something you should read and understand before you get into Agile development.
Comments