Agile - why it's different

When I talk to my management or other developers they often express that they see Agile Software Development and Software Engineering as conflictive approaches to software development. To me that's not exactly a true story. One reason I say that is that you will (most likely) not go to university to become an "Agilist", right? Instead you go there to become a Software Engineer, you want to learn

"[...] a systematic approach to the analysis, design, assessment, implementation, test, maintenance and re-engineering of a software by applying engineering to the software [...]"

And yes, here, "systematic" does also mean "agile". Consequently, I look at Agile Software Development as being a sub-discipline in Software Engineering. In that broad subject area "Agile" is "only" a specific category of software development processes. Now, I totally agree that Agile Processes differ from more traditional approaches like Waterfall Model, Spiral Model or Iterative and incremental Development. But what's the essential difference? To me the following characteristics are extremes in a continuum of different software development philosophies:

Traditional software development processes are considered heavyweight. What does that mean? Firstly, they were described in comprehensive (very dry) process documents. Nobody I know really ever read through these documents. They were just to large. Secondly, these processes also suggested lots of documentation during the software development process. It was the firm conviction of the authors of these processes that one could measure project progress with "finished" documents.

In agile Methods the only work product that one can measure project progress is "running software". Documents (if created) fulfill just the purpose to create a running piece of software. In an agile team you prefer coding rather then documenting, if both of it leads to success. And again, success means deploying high quality software to production. Only the software adds value to our client's business. In addition, the process description of agile processes are very condensed. These processes suggest only a minimal set of work products and meetings. Therefore, agile processes are considered lightweight.

"micromanaged" vs. "self-organizing"

Another essential difference between agile and traditional processes is in the freedom of acting individuals. In agile processes the developers can choose the tools, techniques and individual procedures that lead to success in their opinion. They organize and regulate themself. In traditional processes every little step that the individual is allowed to take is documented. The behaviour of the individual is regulated by the process. The team is organized in exactly the way that the process suggests. That's probably one of the biggest issues of traditional processes: they define the complete process in detail without knowing the problem to solve. In agile processes the teams adapt to the concrete problem they have to resolve. They do that by self-regulation and self-organization.

"cross-functional" vs. "processoriented" (Teams)

Another important difference in traditional processes and agile processes lies in the way they suggest to organize the teams of a project. In waterfall oriented projects you will often see that individuals are organized along the development process. You have an analysis team, a development team and a test team. In agile teams all skills are organized into one single cross-functional delivery team. That team includes the client, the business analyst, the developers, the testers and so on. That way every person involved gets immediate feedback about the work done. In a traditional organization the analysis team works on a funtional specification and then they "throw" it across the fence. Then the developers wonder what the analysis team meant by all that. Continuous feedback about results is not build into that kind of organization.

"developercentric" vs. "managementcenric"

When I look at the process description of traditional development processes my impression is: they were defined so that (project) management can get in control of a software project. Measuring, organizing, regulating, controlling, meetings etc. The process description adresses management problems. In agile process descriptions most (if not all) of the techniques described directly adress the problems of the developers or the team. The focus is to get the individual and the team going, not to get the management in control of the project. To me, the developer, the guy that has to do the job is in the middle of interests in agile process descriptions.

That's it. That is what I can see as essential differences between traditional processes and agile processes. I am not saying that's all. I develop software for 15 years now. In that period of time I had the pleasure ;-) to work in all the different flavors of processes. In my experience they all work. Yes, don't be supprised now. Why I say that? Because in the end it all comes down to the people that do the job. It's the people that are the key to success and not the process. And for the sake of exactly that reason I personally prefer agile.

What's your opinion to all that? Looking forward to read and reply to your comments.