Technology Over Process and How Agile Is Agile?

Should beginner read the agile manifesto (or a scrum/xp/tdd book) or a good java (or ruby,c#, groovy) book first? It seems like more and more people are interesting in more soft, than technology topics.
It would be interesting to do the following experiment: Just observe a novice, but passionate, developer how he (perhaps she) learns the technology. The developer shouldn't have any knowledge about processes, especially agility, lean development or XP. I remember the time, as I started with C++, then Java. In both languages I first implemented a hello world sample, compiled and ran it. Then I played with another samples. I deployed the software after the implementation of an every new feature. The reason: I was curious about the results and a littlle bit afraid of the complexity. Even in my first projects we deployed our software several times a day to the target environment (it was an orbix orb), because it was too complex to deploy the software in longer cycles and the software was really buggy. The developer support wasn't comparable with current IDEs, there was no integration server etc. We didn't used JUnit (it wasn't avaible), but we tested the business logic with some main-methods.
I also worked in parallel with some database exports, often on one machine. I wanted to understand what's going on in the DB. It was a kind of pair programmig, but not the whole time.
I observed my young brother, as he learned programming some years ago, and it was also very iterative if not agile. So I started programming, without any knowledge, in more or less agile while (with a bad feeling, because I wasn't able to design in UML the whole application at the beginning of a project). I also observed my students in trainings with similar results.
My assumption:  If someone is really interesting in the technology or application, and tries to achieve some results, he will probably go the agile way.
I think it is more important to train management or even organizations, than developers to be agile.
Developers also tend to become a little bit dogmatic, after some agile courses or workshops - which is not very efficient in software development. I think the customer and the product (system) and not the process or even technology should be emphasized. But it is hard to build a system only knowing the process and not the technology :-).
It is also very hard, if not impossible, to describe the agile processes, because of the agility :-). In case it is written down it gets a dogmatic touch and developers try to follow hard rules, which is no more agile... Also the naming is cool but confusing (ScrumMaster, standup meetings, in zone, pair programming etc.). Just imagine: you have a team with experienced and motivated developers - is it still needed to talk about iterations etc.? At the other side: in case your developers are not interested in the software they build - do the agile process really help?
I think every developer should now about the processes. Every process has some advantages and trade-offs. But we should not overestimate the soft and process skills. The developers have still to code the software...


Nice perspective. But Technology is just not enough when have been developing/coding for a really long time. Programming is a disease like money. You want more when you get used to the stuff that you have. There is always somethings management shouldn't do, but again it is on the developer that he should clearly demarcate what is messing his mind and should not accept it.

Posted by Giridhar Nandigam on August 16, 2006 at 08:14 PM CEST #


thanks for your comment. I see sometimes, that there is a little inclination to hide behind soundful keywords and buzzwords, instead of concentrating on the system/result.


Posted by Adam Bien on August 16, 2006 at 10:24 PM CEST #

Teach them programming first, not process.

Before any beginner programmer can truely appreciate the benefit of any process (e.g. Agile) they need to fall flat on their face. Have a novice write a complex 5000+ line program as fast as possible in C. Make them create a schedule ahead of time. After that miserable failure, teach them Agile process. Then they'll likely get it.

Posted by Michael Slattery on August 18, 2006 at 07:58 AM CEST #

Absolutely. Thanks!

Posted by Adam Bien on August 20, 2006 at 04:44 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments