agile philosophy

The 'philosophy' of Agile software development is encapsulated in the Agile Manifesto - a set of values and principles defining a modern approach to software development which favours an iterative, incremental approach over the more rigid, inflexible, 'waterfall' style of project delivery.

The Agile Manifesto describes how Agile methods favour ...

Individuals and interactions over processes and tools

We believe that highly skilled and motivated individuals, working together and interacting effectively, make a software development team successful.

Whilst it is not the case that there are no processes and tools in Agile software development, in an Agile project lightweight processes are designed to help and support rather than stifle and constrict the team, and tools are used in a way which is appropriate to the task rather than just because 'that's the standard', allowing the team the opportunity to deliver high quality working software at pace.

Working software over comprehensive documentation

This is a key concept. In an Agile project, the true measure of progress is working software, i.e. production quality software that meets business needs.

In any waterfall-style project, where 'coding' tends to happen later in the project life cycle, progress is traditionally described using bars on a Gantt chart, or via Red / Amber / Green (RAG) reports. Whilst these have their place, it is inescapable that progress is to a large extend being assumed, based on the quantity of documentation which is being produced as well as the quality. Documentation, however comprehensive, can only ever be an indicator of progress, and is not always a particularly good one.

Compare an Agile approach, which incrementally delivers working software which business users can see, experience and give feedback on, with the all-too-common 'waterfall' scenario, in which the project team create an extensive specification (probably running to 50-100 pages), naively expect users to understand the nuances of everything written down in the specification, develop code based on their interpretation of the specification, and then use this same specification as an excuse for the system not providing business users with the functionality they actually need. Clearly, in this situation documentation is not a good measure of progress towards delivery of a system which the users will accept.

Of course, it isn't the case that Agile projects do not create documentation: they do. But only what is absolutely necessary to meet internal or external governance and financial reporting requirments, or what is of value to the team as they work towards their primary goal: delivering working software that meets the business needs.

Customer collaboration over contract negotiation

This statement embodies the idea of partnering: collaboration rather than confrontation. In an Agile project, effective collaboration between 'supplier' (the development team) and 'customer' (the business users) is key.

This is not to suggest it is not possible to enter into a contract (whether a commercial supplier / customer contract, or an internal contract). But even within the constraints of a formal contract, Agile places emphasis on collaboration, and a shared desire to achieve success rather than a focus on protecting vested interests.

Responding to change over following a plan

Agile project managers know that requirements have a tendency to evolve and expand as a project progresses.

Uncontrolled change is obviously unacceptable on any project, including Agile projects, and Agile projects still include a planning component, although this is typically more iterative than in a 'waterfall' project.

Agile project teams recognise that change is likely, and project processes must be responsive to change without causing a need to rework the whole project plan, bringing the project to an abrupt halt or incurring excessive cost. In an Agile project, rather than trying to resist or defer changes for the sake of 'sticking to the plan', new or changing requirements are accepted, evaluated and (re)prioritised, enabling the business to reassess which items of functionality are more important and which should be delivered first.