Anyone who has been working in software development over the last 10 years or so will have at least heard of the term Agile. People often talk about doing Agile or being Agile but, beyond a cool-sounding buzzword, what is Agile really all about? Well, to answer that question, we need to look at the origins of Agile software development.

Back in the late 1990s, many senior software developers and industry leaders, fed up with the static and inflexible software development methodologies prevalent at the time, were already experimenting with more flexible and responsive techniques and approaches. In 2000 and 2001, a small group of these influencers met up to discuss these methods and techniques. The unifying theme behind this effort was a desire to be able to quickly deliver working software to end users and to get rapid feedback on the software's impact and scope. In the forthcoming years, methodologies developed under this philosophy came to be known under the umbrella term of Agile.

The Agile philosophy is best captured in the Agile Manifesto (2001), which identifies the following 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

The Agile Manifesto clearly states that while there is value in the items on the right of this list, we value the items on the left more. So, it is not an abandonment of the old values, but a realization that some new values (individuals and interactions, working software, collaboration, adapting to change) are far more relevant in the modern software development world. In addition, they also came up with a set of principles (see Principles behind the Agile Manifesto in the Further reading section), emphasizing continuous delivery, frequent feedback, personal interactions, and much more. These principles are as follows:

• 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 every couple of weeks to every couple of months, with a preference for a shorter timescale.
• Businesspeople 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.

It becomes clear that Agile is not a specific methodology, process, or framework but more of a mindset; a set of principles and ideals to guide us through the software development process.

This is a rather important concept to keep in mind: throughout my career, I've heard managers, directors, and developers boasting about being Agile because they have daily stand-up meetings, practice pair-programming, or use a Kanban board (more on these in Chapter 7, The Sprint Journey). All these are perfectly good tools to support an Agile development lifecycle, but their use alone does not make us Agile any more than wearing a cape and my underwear outside my pants makes me a superhero. To truly be Agile, you have to think and act in an Agile manner, that is in a manner consistent with the Agile Manifesto. One of the most popular ways of being Agile is by applying Scrum in your organization or team.

With this in mind, let's take a closer look at the Scrum framework.