Agile Software Development

I have consolidated some good definitions and principles on the topics Agile Development / Tacit Knowledge / Web 2.0

What Wikipedia says about Tacit Knowledge :

Some companies are very picky at making sure that all their employees got a project to work on. Especially the top engineers. I've seen quite many environments, where senior guys are the ones who have to be "120% utilized" and who are actually doing the work, while juniors are expected to be floating around doing "something not critical" and being asked to help seniors, whenever those would need an extra hand.

Agile processes often enter the organization from the grass roots - from the developers appreciating useful practices and insightful low level managers seeking for ways to help their subordinates. However, if things progress well, at some point the top management might buy the idea of delivering incremental software faster, than the competition, and declare "we are going Agile" or even "we are going AGILE". While the top management support is something to appreciate, there is still a number of issues to be aware of, when restructuring mid to large size organizations. One of the most important changes is the potential career ladder restructuring.

Many if not most of software development companies employ some kind of the bonus plan for their developers. Developers or teams get a set of targets to reach and depending on the target fulfillment the bonus is paid. The idea of compensating the extraordinary performance and success is a good one. Unfortunately there two major problems with the bonus plans:

Expected bonus is not a reward

As Joel Spolsky puts it "They [bonus plans]'ve become like tips in restaurants: everyone expects one, so they can no longer be used well to award performance". Most of the good managers I've heard of try to plan the bonus targets so that their subordinates would get about the same amount of money whatever happens.At the time when there is a reasonable lack of programmers everywhere, it is just too dangerous to have an employee that expected the bonus, but didn't get it. The received bonus feels like something expected, while the one that was not received feels like a punishment and most of bosses wouldn't like their employees to feel punished.

Individuals and interactions over processes and tools © agilemanifesto.org

Lately on a Russian programmer forum I've read a story about the usual victory of a process over the individuals.

One software development company had Windows and Unix stations. As a result from time to time the wrong endline characters leaked into the repository and caused the build breaks. There were two ways to overcome the problem:
1. To oblige everybody to check the files before the commit

Scrum Master role in the Scrum development method in the first place "was designed to change the power relationship and interaction dynamics from the traditional Team Lead or Project Manager". Scrum Master organizes the daily meetings, removes the impediments, reminds the Sprint goal, often maintains the Sprint backlog and does other secretary-like work.

When there are more, than one programmer on the project, the work has to be divided somehow. Agile methodologies propose self-organized team to decide who is doing what, more traditional waterfall approaches propose that manager allocates tasks to the guys with the free time slots. Whatever the method is, there is one more thing to consider: who is allowed to make changes where.
It is quite often that particular modules are "owned" by particular people and only they are allowed to make reasonable changes there. Usual argument is "The person, who doesn't know the module, can unintentionally break it".