Agile (in general)

By the early 1990s, a sea change was under way in how development processes were viewed. The Waterfall process, despite widespread adoption, even in government contractor policies in the US, started to show more and more of the flaws inherent to its application to large and complex systems. Other, non-Waterfall methodologies that were in use were also starting to show signs of wear from being too heavy, too prone to counter-productive micro-management, and a variety of other complaints and concerns.

As a result, a lot of thought around development processes started focusing on lightweight, iterative, and less management-intensive approaches, that eventually coalesced around the Agile Manifesto and the twelve principles that underlie it:

• We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. We follow these principles:

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

In an application, these principles lead to a few common characteristics across different methodologies. There may be exceptions in other methodologies that are still considered Agile, but for our purposes, and with respect to the specific methodologies discussed here, those common traits are as follows:

• Development happens in a sequence of iterations, each of which has one to many goals
• Each goal is a subset of the final system
• At the conclusion of each iteration, the system is deployable and operational (perhaps only for a given value of operational)
• Requirements are defined in detail in small chunks, and may not be defined at all until just before the iteration that they're going to be worked on

Scrum is claimed to be the most popular, or at least most widely used, Agile development methodology (the 12^th Annual State of Agile Report puts it at 56% of Agile methods in use), and as such is probably worth some more detailed attention. Kanban is another Agile methodology that bears some examination, if only because it's closer to how the main system project in this book is going to be presented.

There are a few other Agile methodologies that also bear at least a quick look-over for some of the specific focus they can bring to a development effort, either on their own, or as a hybrid or mix-in with other methodologies.