1

The primary subject of this lesson is the Agile Manifesto Values and Principles, but before we get into that, I think it’s useful to quickly review some of the history that led to the development of the Agile Manifesto.

2

Software development prior to the Waterfall Model was somewhat unstructured and chaotic. You also have to appreciate that the technology for doing software development in those days was much more primitive than it is today. In those days, software development tools were not very sophisticated, development languages were much more limited, and software development patterns and architectures were also not as well-defined as they are today.

The process for developing software in those days might be compared to the process for knitting a sweater by hand…it was an art and required a lot of craftsmanship and the process was very primitive compared to today’s standards. And it wasn’t just the process that was the problem, the technology and tools were primitive as well at that time.

• The nature of the technology and the process required a heavy emphasis on upfront design -can you imagine trying to knit a sweater without knowing exactly what it’s going to look like before you start?

• It was also difficult to scale that process - it’s like getting multiple people to try to knit the same sweater – it’s a very difficult thing to do and it can be very prone to error and problematic if the efforts of multiple people weren’t very carefully planned and coordinated.

3

One of the major reasons that processes like the Waterfall model evolved was to bring structure and discipline to that development process. That was absolutely essential as projects grew larger as well as more complex and more critical.

It’s important to recognize that because as we migrate to a more Agile approach, we don’t want to lose sight of that and go back to a completely unstructured approach and all the problems that existed prior to the Waterfall approach.

4

The process for developing software after the evolution of the Waterfall model might be compared to a manufacturing process for knitting a sweater in a manufacturing plant. It required a lot less individual craftsmanship and the process was much more structured, controlled, planned, and organized.

That resulted in higher levels of quality and standardization as well as compatibility; but, of course, the downside of that was because the products were more standardized and controlled, the process was naturally much less flexible and required defining the requirements upfront.

You might compare it to the evolution that manufacturing processes went through to go from the age of craftsmanship to highly controlled manufacturing processes that came about with the industrial revolution and manufacturing assembly lines.

5

The Waterfall process was an improvement over what came before it but it certainly wasn’t optimal. The pendulum really swung pretty far between two extremes from a highly unstructured approach based on individual craftsmanship to a very highly structured approach that was heavily controlled, planned and organized.

The problem is that designing and developing software isn’t really totally like a manufacturing process at all because the requirements aren’t necessarily well-defined before you start. As a result, it isn’t as simple as building the same product over-and-over again on a manufacturing assembly line.

6

In reaction to the problems caused by an excessive emphasis on control in the Waterfall model, the pendulum started to swing back in the other direction in the 1980’s and 1990’s with a variety of iterative and incremental approaches such as the Rational Unified Process (RUP).

Agile methods really had their roots in the 1980’s and 1990’s in some methodologies that became popular at that time such as Joint Application Development in 1986 and Rapid Application Development in 1991. However the roots of Agile really can be traced into a number of manufacturing advances that came about at that time such as Total Quality Management which we will discuss in a later lecture.

7

There was a broad proliferation of Agile methodologies that evolved in the 1990’s; however the popularity of Extreme Programming was the singular event in 1999 that led to the unprecedented success of Agile methods by the early 2000’s.

8

The proliferation of all those Agile methodologies led to the Agile Manifesto which was originally written in February of 2001 at the Snowbird Ski Resort in Utah. The Agile Manifesto was a very important milestone in synthesizing the underlying values and principles behind many of the diverse range of Agile methodologies that had developed up until that time.

The original Agile Manifesto value and principles were written around a software development environment, but they are really much more general than that and can be applied to some extent to almost any kind of project. For traditional project managers, it forces us to “think outside of the box” that there are different ways of managing a project and you have to tailor the approach to the project.

When we discuss the Agile Manifesto and the principles behind it, we will talk about it primarily from the perspective of a software development project but that is not meant to indicate that it is limited to software development only.

9

One of the most important things to recognize about the Agile Manifesto and the principles behind it is that they must be interpreted in the context of whatever project they’re applied to. The Agile Manifesto consists of four values and a number of principles that back up those values.

The value statements are not meant to be absolute statements at all and the Agile Manifesto clearly states that; however, in spite of that many people have made the mistake of dogmatically treating these statements as absolutes. You need to think about these statements in a broad sense and interpret them in the context of a particular project. If you take that approach, they make sense to be applied to almost any project.

This slide shows the four Agile Manifesto values and next, we’re going to talk about each of the values individually.

10

The first Agile Manifesto value statement indicates a preference for “individuals and interactions over process and tools”.

This statement is essentially a response to “command-and-control” project management practices that had been perceived as very impersonal and insensitive to people and rigidly-defined processes where the “process manages you”.

From a project management perspective, it calls for a softer leadership approach with an emphasis on empowering people to do their jobs rather than a rigid, control-oriented management approach that is highly directive as well as flexible and adaptive processes.

The last part of this statement regarding “process and tools” might imply that there is no place in an Agile project for process and tools but that is certainly not the case.

• Agile does use very well-defined processes like Scrum but they are meant to be interpreted and implemented intelligently by people rather than following them rigidly and mechanically.

• Tools can also play a supporting role, but the important thing is to keep the tools in the right context – they should be there to leverage and facilitate human interactions not to replace them.

The important point is that Agile processes generally depend very heavily on empowered people making intelligent decisions and the power of collaborative teamwork

11

The second value statement indicates a preference for “working software over comprehensive documentation”. This statement is essentially a response to typical phase-gate project management processes that called for extensive documentation deliverables at the end of each phase. There was entirely too much emphasis on producing documentation to the extent that the documentation took on a life of its own and there was insufficient emphasis on producing working software.

One of the problems with documentation is that it can inhibit normal communication. The typical Waterfall project was heavily based on documentation. The project team would develop an elaborately detailed requirements specification and the software was tested against meeting that specification. In many Waterfall projects, the end-user doesn’t even see what is being developed until the final user acceptance testing at the end of the project. There are lots of opportunities for problems with that approach:

• Many users have a difficult time defining detailed requirements upfront in a project especially in a very uncertain and changing environment

• Relying too heavily on documentation can lead to significant miscommunications and misunderstandings about the intent of the requirements

Its important to note that this statement doesn’t imply that there should be no documentation at all in an Agile project. The key thing to recognize is that any documentation should provide value in some way. Documentation should never be an end in itself.

12

The third value statement indicates a preference for “customer collaboration over contract negotiation”. The typical project prior to Agile has been sometimes based on an “arms-length” contracting approach. Project Managers for many years have been measured on controlling costs and schedules and doing that has required some form of contract to deliver something based on a defined specification and that also requires some form of change control to limit changes in the requirements as the project progresses.

Agile recognizes that particularly in an uncertain environment, a more collaborative approach can be much more effective. Instead of having a strong, iron-clad contract to deliver something based on some pre-defined requirements, it’s better in some cases to create a general agreement based on some high-level requirements and work out the details as the project progresses. Naturally, that approach requires a spirit of trust and partnership between the project team and the end-customer that the team will ultimately deliver what is required within a reasonable time and budget. Without that spirit of trust and partnership, it will be almost impossible to make this approach work.

Again, it’s important to recognize that these values are all relative and you have to fit this statement to the situation. At one extreme, I have applied an agile approach to a government contracting environment. Naturally, we had to have a contract that called for deliverables and milestones and expected costs but even in that environment, the government agency understood the value of collaboration over having a rigidly-defined, arms-length kind of contract and we were able to find the right balance. At the other extreme, you might have a project where the requirements are very uncertain and a much more adaptive approach is needed to work collaboratively with the customer to define the requirements as the project progresses without much of a well-defined contract at all.

13

The final value statement indicates a preference for “responding to change over following a plan”. This statement is in response to many projects that have been oriented towards controlling costs and schedules and made it difficult for the customer to change the requirements in order to control the scope and, hence, the cost and schedule of the project. The problem in applying that approach to environments where the requirements for the project are uncertain and difficult to specify upfront is that it forces the user to totally define the requirements for a project upfront without even seeing what the final result is going to look like and that’s just not a very realistic approach in many cases.

In many situations, it is more effective to recognize that some level of requirements are going to change and evolve as the project progresses and design the project approach around that kind of change. It’s important to recognize that this is not an all-or-nothing decision…to have either completely undefined requirements are highly detailed requirements. There are a lot of alternatives between those two extremes and you have to choose the right approach based on the nature of the project.

All of these statements are somewhat inter-related and you have to consider all of them in concert to design an approach that is appropriate for a particular project. From a project management perspective, it calls for some skill to be able to do that. Instead of force-fitting a project to some kind of canned and well-defined methodology like Waterfall, the project manager needs to intelligently develop an approach that is well-suited to the project - that applies to any project, not just Agile.

14

In the next lecture, we’re going to discuss the Agile Manifesto principles.

Thanks for taking the time to do this lecture and I’ll look forward to working with you in the rest of the course.

15