The discipline of software engineering brought us Agile as an improvement over what they had used before. Since the 1970s, older methods have been used for software development. The software development life cycle (SDLC) is one of these older methods.

The SDLC included a linear process of sequential phases with the work flowing down through the process steps like a waterfall, thus the nickname the waterfall method.

Some models show these phases as requirements, design, implementation, verification and maintenance.[1]

The older waterfall methods expected that the customer knew exactly what they wanted at the beginning of a project with their requirements document specifying what they wanted. Experience has proven that what customer’s want has tended to change during a project. Over time and from many projects, software developers had experiences that indicate that customers do not always know exactly what they want up front, that they often change their requirements during the project. Because software projects can take so long, sometimes even the customer’s business changes during long projects. This experiential data from software development also matches human nature at not often getting work done exactly right the first time. Change happens constantly. This may sound familiar in learning experience development, too.

By the late 1990s, many software development practitioners felt these older methods were too slow, too strict and encumbered by too many document artifacts. Experimenters, like Jeff Sutherland and others, started developing alternatives to the heavy-weight waterfall SDLC process. These experimenters sought lighter-weight methods. Then in 2001, a group of software development practitioners got together in Snowbird, Utah to discuss light-weight methods. This group worked together to write what they called the Agile Manifesto for Software Development in an effort to influence other practitioners of Software Development. The manifesto writers included practitioners of various software development methods such as Adaptive Software Development (ASD), Agile Unified Process (AUP), Crystal Clear Methods, Disciplined Agile Delivery (DAD), Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Feature-Driven Development (FDD), Lean software development, Kanban, Scrum and Scrumban. They wanted better options than the SDLC (often called waterfall, documentation-driven, or plan-driven). They named themselves the Agile Alliance.

It is beyond the scope of this book about training to describe each of these light-weight methods of software development.

The Agile Alliance also wrote their principles of Agile for software development. It is these principles that we will apply to training.

The principles indicate that instead of focusing as much effort on up-front planning and detailed requirements, Agile methods place more emphasis on:

  • Continual planning that gets distributed across the project

  • Cross-functional teams rather than handoffs between departments of specialists

  • Team collaboration

  • Emergent design

  • Functionality testing early and often

  • Frequent delivery of working software in short iterations

Agile is an umbrella term that describes principles that are derived into various light-weight methods. Software developers as a community have many discussions and arguments about Agile. It is a spirited discussion that provides good insights. Other than the Agile Manifesto, there is no consensus on a definition of the term Agile for software. We propose a definition for the purposes of this book in the glossary. Agile can mean any group of development methods that apply the Agile principles. Software practitioners also have good discussions about partial versus full implementations of Agile. We will address that later. For the purposes of this book, we will stick to the idea that if you are applying Agile principles in your specific context, then it is okay if your specific methods vary. Because we are applying Agile principles to learning experience development, our methods will necessarily vary somewhat from popular software development Agile methods as we experiment and adapt.

Managers may perceive Agile as anti-process or anti-methodology. Agile is not anti-process or anti-methodology, but seeks lighter-weight processes over heavy-weight processes. Planning is okay in Agile too. Agile recognizes that plans have limits in complex situations. We discuss this in more detail later. Artifacts that document process are okay in Agile. Agile tends to focus on light-weight, meaning short for documents, rather than long. Lighter-weight encourages actual use. By counter example, heavy-weight plans use lots of boiler plate text, are ill-maintained and consequently teams rarely use them.

Since the 2001 Agile Manifesto, Agile has spread to many more groups making software. One Agile practitioner, David Andersen, applied lessons from other industries as he continued to experiment and adapt. David adapted Lean thinking from manufacturing into software product development, naming his method Kanban. Lean principles increasingly have been integrated into Agile. We will discuss Lean more in the next section [Lean].

The rapid rate of adoption of Agile methods for software development has resulted in many software developers being aware of and using various Agile methods. In contrast, awareness of Agile approaches in the learning and development discipline is just beginning. Usage of Agile is also just beginning. The improvements Agile brings to project results such as cost, schedule and customer satisfaction have begun to catch the attention of other industries. Even the U.S. Federal Government is beginning to allow Agile development methods in its procurement of software products. Agile now has certifications from the Project Management Institute.

1. Reproduced from Wikipedia article "Waterfall model," (accessed December 14, 2015) under a Creative Commons Attribution-ShareAlike 3.0 license.

Line By Line

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

Back to Overview