There have been many attempts to try and improve software development practices over the years, and many of these have looked at working in a more iterative way. These new practices didn’t go far enough when trying to deal with changing requirements of customers.
In the 1990s, a group of industry software thought leaders met at a ski resort in Utah to try and define a better way of developing software. The term “Agile software development” emerged from this gathering. The term was first used in this manner and published in the now-famous
Agile Manifesto. The Agile Manifesto was designed to promote the ideas of delivering regular business value to your customers through the work of a collaborative, cross-functional team.
The Agile Manifesto Core Values
The Agile Manifesto is built upon four core values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Individuals and interactions over processes and tools
Software systems are built by people, and they all need to work together and have good communications between all parties. This isn’t just about software developers, but includes QA, business analysts, project managers, business sponsors, senior leadership, and anyone else involved in the project at your organization. Processes and tools are important, but are irrelevant if the people working on the project can’t work together effectively and communicate well.
Working software over comprehensive documentation
Let’s face it—who reads hundred-page collections of product specs? I certainly don’t. Your business users would much prefer to have small pieces of functionality delivered quickly so they can then provide feedback. These pieces of functionality may even be enough to deployto production to gain benefit from them early. Not all documentation is bad, though. When myteams work on a project, they use Visio or a similar tools to produce diagrams of employment environments, database schemas, software layers, and use-case diagrams (and this is not an
exhaustive list). We normally print these out on an A3 printer and put them up on the wall so they are visible to everyone. Small, useful pieces of documentation like this are invaluable.
Hundred-page product specs are not. Nine times out of 10, large items of documentation are invalid and out-of-date before you even finish writing them. Remember, the primary goal is to develop software that gives the business benefit—not extensive documentation.
Customer collaboration over contract negotiation
All the software that you develop should be written with your customer’s involvement. To be successful at software development, you really need to work with them daily. This means inviting them to your stand-ups, demoing to them regularly, and inviting them to any design meetings. At the end of the day, only the customer can tell you what they really want. They may not be able to give you all the technical details, but that is what your team is there for: to
collaborate with your customers, understand their requirements, and to deliver on them.
Responding to change over following a plan
Your customer or business sponsor may change their minds about what is being built. This may be because you’ve given them new ideas from the software you delivered in a previous iteration. It may be because the company’s priorities have changed or new regulatory changes come into force. The key thing here is that you should embrace it. Yes, some code might get thrown away and some time may be lost, but if you’re working in short iterations, then the time lost is minimized. Change is a reality of software development, a reality that your software process must reflect. There’s nothing wrong with having a project plan; in fact, I’d be worried about any project that didn’t have one. However, a project plan must be flexible enough to be changed. There must be room to change it as your situation changes; otherwise, your plan quickly becomes irrelevant.
