Agile Manifesto

It may help to review the Agile Manifesto [1] (modified slightly for training) that articulates principles. These principles were articulated by the Agile Alliance.

We are uncovering better ways of developing software [courseware] by doing it and helping others do it.[1] Through this work we have come to value: [1]

  • Individuals and interactions over processes and tools [1]

  • Working software [courseware] over comprehensive documentation [1] [of intent]

  • Customer collaboration over contract negotiation [1]

  • Responding to change over following a plan [1]

That is, while there is value in the items on the right, we value the items on the left more.[1]

When you plan new efforts where experimenting and failure will be necessary, the plan is the best guess with what we know at the time we write it. To pretend it is more than the best guess at the time increases risk.
In some organizations, the development teams have no control over contracting with the customer, so they may not be able to apply "Customer collaboration over contract negotiation" at all or not perfectly. This is where the application of the principle will allow you to come up with a practice that works for your context.

Agile Principles

The site states the following principles for Agile. At this point in the book we will simply restate them as originally articulated by the Agile Alliance at with only slight replacement of software with courseware.[1]

Principles behind the Agile Manifesto [1]

We follow these principles: [1]

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software [courseware].[1]

  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.[1]

  • Deliver working software [courseware] frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.[1]

  • Business people [customer stakeholders and SMEs] and developers must work together daily throughout the project.[1]

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.[1]

  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.[1] [When geographically dispersed, we adjust and use conference lines. Face-to-face is the ideal.]

  • Working software [courseware] is the primary measure of progress.[1]

  • Agile processes promote sustainable development. The sponsors, developers and users [, stakeholders, SMEs and reviewers] should be able to maintain a constant pace indefinitely.[1]

  • Continuous attention to technical excellence and good design enhances agility.[1]

  • Simplicity—​the art of maximizing the amount of work not done—​is essential.[1]

  • The best architectures, requirements, [content] and designs emerge from self-organizing teams.[1]

    We adjust this principle slightly to 'directed self-organizing teams' by giving people a clear purpose and defined goals and constraints as boundaries. Ex-military folks will see this as similar to the Commander’s Intent portion of an operations order. For those not familiar with this, it allows lower unit leaders the freedom from being told exactly how to get it done, and to change the way they respond to the situation so long as they help the parent unit achieve its objectives. This rephrasing of self-organizing tends to be more palatable in organizations.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.[1]

1. Reproduced by permission stated on, "may be freely copied in any form", 2001 copyright belongs to the 17 authors listed on that site. We have only added courseware in brackets to indicate how the same idea applies to training.

Line By Line

Here a Little, There a Little, Layer by Layer.

Back to Overview