Agile Revolution

(The following is 'work in progress'. MikeBeedle)

Dear agileers,

This article argues that Agile Software Development _is_ a true paradigm shift in the Kuhnian sense, or maybe an important historical accident in the Feyerabend sense.

Undoubtedly we live in a world where there is a software crisis. This crisis has existed in different forms since about 50 years. Defined process methods attempted to solve this crisis, but clearly failed. And software failure is as pervasive today, or more, as it was before the wave of Defined-Process methods that came to us from manufacturing strategies in the mid 70s. The crisis primarily comes from anomalies that have plagued our industry. We simply can't explain from current paradigms how software can be developed faster, with quality, bounded by cost, and within margins of scope.

Agile Software Development presents an alternative to Defined-Process methods that attempts to solve and explain these anomalies. In time, I foresee that Agile Software Development can replace the old paradigm of Defined-Process methods by completing a "scientific revolution" in the field of software development methods. (Whether Kuhn applies here is also debatable but what other alternatives there are to explain what goes on?)

Also, Kuhn warns that the new paradigm needs to be perceived as "better" by the majority of people with power and influence. So I beg your endorsement.

It troubles me that the _fundamental differences_ between traditional and agile processes are not highlighted, either by the creators and supporters of the Agile movement, or by traditional software development figure-heads.

Because if we don't highlight the differences of why Agile Software Development processes, we run the danger of hearing and, worse, accepting that:

there is nothing really all that new with Agile Software Development processes

This will relinquish Agile Software Development as "one" of many other compatible worldviews, and soon Agility will be muddled into oblivion.

Don't take me wrong, I admire and respect the contributions of people like Humphrey, Paulk, Parnas, Boehm, Constantine, DeMarco, Booch, Jacobson, Rumbaugh, Gilb, Jackson, Yourdon, etc.; but I think in our desperate effort to make sense of Agility, we will find that many important concepts from the Agile paradigm will be forgotten if we try to equate them with their traditional software development counterparts, and that misconceptions and misunderstandings will be created like:

The CMM is compatible with agile processes, or XP can be an instance of RUP

In my opinion, there are radical and fundamental _differences_ that make Agile Software Development Processes and Traditional Software Development Processes two very different ways of developing software from the perspective of the nature of their underlying processes:

Defined-Process Software Development methods advocate and eventually prescribe a _defined_ and _repeatable software engineering process, as well as many other _defined_ and _repeatable_ processes that correspond to different "process areas". And they are based on the erroneous belief, in my opinion, that software can be "manufactured".

But,

Agile Software Development Processes, on the other hand, use inspection/adaptation feedback cycles that "generate" a process by people that self-organize based on the application of a set of practices, or patterns really, that in an Alexandrian way lead to the emergence of an organization and a process. That's easy to understand because at its core, Agility always involves "embracing change" and therefore always requires a considerable level of self-organization.

This is stated directly in the Agile Principles:

"The best architectures, requirements, and designs emerge from self-organizing teams." http://www.agilemanifesto.org/principles.html

Therefore Agile Software Development Process more closely resembles a New Product development process like the one described in:

[NonakaTakeuchi?] Takeuchi H. and Nonaka I., The New New Product Development Game, Harvard Business Review (January 1986), pp. 137-146, 1986.

In my opinion, this process difference, self-organization, is a very important, radical and fundamental _difference_, that subtly changes the underlying assumptions of why and how things work in a software development process.

And that in fact, this difference, self-organization, suffices to label Agile Software Devlopment as a paradigm shift, as defined by Thomas Kuhn, because it is an essential and pervasive difference.

How does this difference affect the people that work on an Agile Software Development Process?

It is this feature of Agility, self-organization, that brings out some of the essential characteristics in an Agile Software Development Process:

1. Management Pyramid is inverted

In true Agile practice the management pyramid is inverted:

2. Greater Liberty and Freedom to accomplish the task at hand

People in an Agile Software project feel more liberated because they feel _free_ to self-organize to do whatever it takes to achieve their goal:

talk to the customer, think, imagine, code, test, refactor,

in any order, as many times as they need/want, and as often as they need to.

3. Constant Learning, Knowledge Creation and Knowledge Sharing

People in an Agile Software project are constantly learning, and sharing knowledge, in an ad-hoc way, because by definition Agility is based on continuous short feedback cycles of:

inspection --> adaptation

where we learn from the customers, from other team members, from practitioners in the field, and even from ourselves on a daily basis. In agility learning and knowledge sharing happens opportunistically and serendipitously.

4. A More Enjoyable and Humane Work Environment

People in an Agile Software project participate in a more human "fun-like" way because the more human and intellectual activities of research, understanding, imagination, creativity, cooperation and sharing are encouraged and required; as opposed to being considered just "another station in a production line". And these activities, by their own nature are not, can cannot be structured in a step-wise process.

For example, there is no defined process to invent or create something.

5. A Hyper-productive Cooperative Work Mode

People in an Agile Software project work in teams that exhibit a mode of cooperation that leads to hyper-productivity - the dynamic pull-system way that Nonaka and Takeuchi describe in the Knowledge Creating Company as the "hypertext" organization.

This way of working relies on dynamic and opportunistic cooperation episodes that are bound by social relationships that don't depend on a defined process.

This mode of cooperation, taps into the collective intelligence and collective knowledge and memory stored in the distributed mind of the team and the organization as a whole.

6. Emergent Planning, Architecture and Requirements

Agile Software projects work under the assumption and expectation that "emergent" behavior is the only way to confront uncertainty. Agile Software projects openly accept that it is impossible to:

outline what tasks are going to be needed to complete a software project up-front, and

get all the requirements up-front, and/or design an architecture up-front.

Rather, the plan, the requirements and the architecture of the project, gradually emerge, by constant feedback cycles, research and creativity, and constant interaction among the participants of the project and the customer.

7. New values that generate a cooperative culture

When operating in a self-organized mode its values change because the team members are now collectively responsible and in control of the team's accomplishments. Therefore, the values of helping others, sharing knowledge, honesty, emerge as the team changes its mode of operation.

In contrast, the command and control, Master-Slave relationships of defined-process relegated developers to be responsible primarily of their own tasks, generating less cooperative values like perfectionism, being accountable and dependable.

8. The Quality of Life

Self-organization is what gives Agile Software Development teams the distinctive feature of "ordered chaos" that Life itself uses to accomplish its miraculous chores.

And therefore, this is what literally makes teams more "alive", because teams more closely resemble living systems like ant or bee colonies, brains, or rugby/soccer/football teams.

etc.

For these reasons, which are not all, I hereby declare the beginning of a new era in software development, and I therefore proclaim officially that the creation of the Agile Manifesto:

http://www.agilemanifesto.org/

and its principles:

http://www.agilemanifesto.org/principles.html

mark unequivocally the beginning of the:

Agile Software Development Revolution

which was created, sponsored and supported by all of you brave souls that dared the world by practicing and advocating a _new_ Agile way, that makes software development different, more productive, more humane and therefore clearly better, in my opinion.

Don't find yourself muddled out by figureheads ... stay Agile!

Let's change the world, let's make it an agile world!

Lastly, I think the ultimate driver for the success of the Agile Revolution will be ROI (return on investment):

If companies and projects find Agile Software Development useful and valuable by generating lower cost, high value, on-time software with adjustments in scope - which is what Agile for the most part means,

I think this will ultimately drive its absorption into the mainstream. This is the value of the competitive dynamics of capitalism,

-- MikeBeedle

http://www.agilescrum.com http://www.xbreed.net

See AgileRevolutionDiscussion

EditText of this page (last edited August 31, 2004) or FindPage with title or text search