Agile Methodologies: Agile Manifesto and Principles

As part of my learning process about Agile Methodologies, I am adding a few notes about Agile in general and some of its methodologies in particular. Part of a series of posts, the first entry is about the Agile Manifesto and Principles. This and the following entries rely on the ‘Agile Software Development Ecosystems’ book, by Jim Highsmith (co-author of the Agile Manifesto and co-founder of the Agile Alliance, and the Agile Project Leadership Network), and materials from the ‘Agile Methods’ course, at Oxford University.

What is Agility?

“Agility is the ability to both create and respond to change in order to profit in a turbulent business environment” – Jim Highsmith

Agile Manifesto Values

  • Individuals and interactions over processes and tools

Agile puts more emphasis on people and how they interact and the quality of interactions; rather than on documented processes with hostile interactions.

  • Working software over comprehensive documentation

Agile teams rely on temporary documentation, and only turn it into long-lasting documentation if and when required. Working software is a more reliable means of measuring progress; than comprehensive documentation.

  • Customer collaboration over contract negotiation

Joint decision making, relationship between the people who want the system and those who are building it.

  • Responding to change over following a plan

All Agile methods plan, but they provide mechanisms for changing priorities rather than following an outdated plan. Agile emphasises time-boxing with re-prioritization after (or near the end of) the short time-box.

“That is, while there is value in the items on, the right, we value the items on the left more.” – Manifesto for Agile Software Development

Agile Principles

The goal is to satisfy the customer; by providing opportunities for feedback about the requirements, team and processes.

  • …through early and frequent delivery of valuable software

Delivering software early, even if incomplete, allows for feedback and mid-course project corrections.

  • …from a couple of weeks to a couple of months, with a preference for the shorted time scale

Time-boxing provides a regular rhythm for teams and stakeholders; and forces a step back to review and re-plan. A stop date forcing us to review items as done or not done.

  • Working software is the primary measure of progress

Demonstrating progress, through evolutionary delivery.

  • Welcome changing requirements, even late in development

Prioritization and trade-offs.

  • Agile processes harness change for the customer’s competitive advantage

Build upon earlier decisions, iterate towards a final goal.

  • Business people and developers work together daily thought the project

Importance of communication, allowing for informal conversations that reduce the likelihood of incorrect assumption making.

  • Build projects around motivated individuals

Projects succeed because of people, by giving them space to do stuff.

  • Give the environment and support they need, and trust them to get the job done

The role of both the team and management in identifying and removing impediments from the team’s path.

  • Face to face conversation

Help avoid misinterpretation and assumptions.

  • The best architectures, requirements and designs emerge

Locked down architectures, requirements or designs, can not be adjusted; and can lead to surprises.

  • …from self-organising teams

Taking small steps can harness the changing knowledge. Utilize the best of people on the team, and not constrain them to a particular role.

  • Attention to technical excellence and good design

Review, reflect, and improve as our understanding improves (e.g.: through refactoring, test driven development, pair programming). Balance technical excellence with delivering functionality. Overemphasizing can jeopardize a project. A tidy, well-encapsulated design is easier to change.

  • Agile processes promote sustainable development

Tired people make mistakes.

Simplicity is not easy. Producing a simple design that can handle change effectively is difficult.

  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

Get together and reflect. Allowing the team to self-organise, with guidance for improving effectiveness. Make 1-3 changes at a time, and do more later.

Agile software development is not about a new process; or new programming practices. Agile software development is a new set of values and philosophy. Techniques from different processes (e.g. Scrum, XP) can be combined, according to needs. It is better to implement smaller elements, before making more changes. Known to work in multi-team projects, although current processes don’t specify how to handle such projects. Agile development doesn’t offer immediate benefits, you need to make changes will take time to do properly.

As a summary of the above, Agile focuses on communication and feedback, rather than processes and outdated plans; allowing for mid-course corrections by involving teams, managers and customers daily, throughout the process. Small iterations produce working software, demonstrating progress and increasing flexibility. Barely sufficient, temporary, documentation is better than comprehensive documentation, but no working software. Time-boxing ensures a steady rhythm, allowing for taking a step back to review and re-plan; with a stop date forcing teams to review items as done or not done. Agile members should have plenty of space for doing things. Allowing teams to self-organise ensures that architectures, requirements and designs emerge, rather than being locked down. Technical excellence is ensured through reviewing and reflecting as our understanding improves. At regular intervals, teams adjust and tune accordingly, without introducing more than 1-3 changes at a time. Iterative over incremental.

This entry relies heavily on course materials from the ‘Agile Methods’ class, at Oxford University.