This is an umbrella term for a group of light weight methods for managing software development. A number of software practitioners had consistently noticed certain weaknesses in the dominant approach of the time and agreed to come together in order to address this problem. A group of these practitioners created an influential document.
The Manifesto for Agile Software Development
agilemanifesto.org/
Many of the principles in this document challenged traditional project management and engineering approaches. This has provoked much discussion and debate however the manifesto itself does not say how a project should be run. It is simply a list of principles.
In large traditional organisations a structure often emerges which makes it very difficult for projects to respond to change. There was a growing tendency to rely on processes, planning, tools and documentation which created a major restriction for developers because it became difficult to respond to change in various areas. Some of these areas are listed below.
- Business Requirements
- Advancements in Technology
- Roles and responsibilities within a team
A number of organisations have acted on these ideas and provide practical advice for how to create agile projects and agile developers. If you want to run an Agile team it is advisable to follow one of these methodologies or at least learn about them.
- Scrum
- Extreme Programming
- Kanban
What about the “traditional approach”?
A popular example is the Waterfall model which is often used in manufacturing. This is a sequential approach where a project is completed in stages. Each stage needs to be completed before the next one begins. For example, initially you find out what is required from the output of the project, i.e. the product. You would not start designing a product until you first understand fully what is required from the project. This makes a lot of sense as long as you can define the requirements because changing a design would create extra work for everything that depends on the design (e.g. the manufacturing process). In a system with physical constraints such as manufacturing it may be impossible to change the design once you start production so you must define all the requirements before you begin.
Yeah, so what’s the problem with that, we can do the same for software
In an information system it is normally very difficult to define all of the requirements before you begin the design. It can be prohibitively expensive to fully define the requirements. Most of the time you can be sure that the requirements for the system will change continuously as the project progresses. Agile methodologies do not attempt to prevent changing requirements they attempt to collaborate with the people who change the requirements.
Then just don’t make changes to the requirements!
Computer systems that have a user interface such as websites or windows applications have an additional factor which is the user. One of the main considerations for this type of system is the usability. This creates a feedback loop where the user will want to change the system as they use it. In addition there are fewer physical constraints so it is possible to change a system.
Okay, so our system is not just dealing with blocks of cheese, it’s dealing with people
Continue reading →
Real World Software 