improve my => 'code' 
One of the interesting features of Agile development is the regular feedback created by the methodology.
Continuous builds, especially when they show graphically when they are broken or have failing unit tests, give Agile teams a sort of self awareness about the health of their project. Many Agile projects even give visual cues regarding the health of the project for instance showing the health of the build through the use of traffic lights (green for good, red for broken).
Likewise, stand-up meetings, burn down charts, and iteration reviews make the team more aware of what they are accomplishing. Whether they are on schedule, what unplanned work they are doing, and what issues are bogging them down are some of the feedback these components of Agile provide. They also calculate the velocity of the team (number of features they can finish in a given iteration), and provide the team ideas for future improvement.
Of course, because iteration work is much shorter and pushes to demo environments are more frequent in Agile development that in more traditional development methodologies such as waterfall, customer feedback is garnered more often.
When Agile is combined with XP (Extreme Programming) techniques (as it often is) such as pair programming, individuals are given very frequent feedback from their coding partners.
In short, Agile methodologies provide the sort of feedback loops that can give an Agile team a sort of consciousness that is unusual for development teams.
Feedback Loops => Consciousness
According to many behaviorists, feedback loops are the strange stuff that cause consciousness in individuals. We are accustomed to speak of consciousness for ourselves. After all we experience a separateness from everyone else, and get constant feedback from our senses supporting our view of separateness. We are also continuously told how we are doing - from friends, family, co-workers even strangers. It is natural for us to think of human individuals having consciousness - as we ourselves are individual humans.
But can a group have its own collective consciousness?
I submit that this is possible, especially if enough feedback systems and punishment/rewards systems are in place.
My Experience
In my experience, the Agile teams in which I have participated have experienced collective joys and disappointments that are much more pronounced than more traditional software development teams.
For example, when a member of the team has inadvertently erred, generally other members will defend the error. Or at least explain the reasoning made for an erroneous choice.
When a teammate departed several months ago, the other three members of his team were shaken for at least a week. We still maintain contact with this fellow, and the relationship goes much further than with other departed teammates. We coded together, not side by side. We taught each other, were challenged by writing our code using TDD (no small challenge in my opinion), and produced code that we can take real pride in.
A few months ago, my team was reshuffled. At first many of us from the newly broken up team thought we were being punished. We were just gelling as a team, and had finished all of the provided work for the last four iterations (and we were really happy that we were meeting our goals!). Of course, I have stayed close with my old teammates (I think they were thrown to the wolves with their project), but my teammates have been wonderful, and I imagine we will be just as close.
Finally, in my office, because we work so closely together, it is certainly possible to develop dislikes as well as likes. It's a good thing we generally get along in my office, as Agile requires working so closely with other developers.
Consequences of Team Consciousness
To be sure, the feedback mechanisms that produce team consciousness make teams more productive. (I estimate that my productivity went up around 30% after switching to Agile.) Additionally I expect that team members are learning more under the Agile approach, mostly as a result of pair programming and iteration reviews. Consequently, long term, this productive may actually widen.
However, the emotional highs and lows are new to me, and I am unsure that this can be easily managed.
For one thing, working with uncooperative developers or developers who will not write quality code is unacceptable in an Agile workplace. There is so much work to be done - performing deployments all of the time, running unit tests, fixing builds besides doing regular development work - that it's harder to take the sort of crud you get from a poor teammate. Jeff Atwood wrote a good post about Dealing with Bad Apples here. My point here is that it's even more important to remove bad apples when using agile management methodologies.
Also, I suspect that when Agile team members undergo changes like teams shuffling or projects ending, a little more time may be needed to digest these changes than what traditional teams need.
Questions for you, the reader:
Q1. Have you noticed a hightened 'team consciousness' since you started using Agile / Scrum?
Q2. If you answered 'Yes' to Q1, how has this experience been different from you traditional software development experience?
Q3. Do you think anything should be added to Agile practices to compensate for 'team consciousness'?
Interested in your thoughts,
Jonathan Starr