Being Agile in a non Agile Environment (Implementing agile practices as we could)

This is the first of a serie of articles about our experience working in a agile/dynamic fashion in a non agile environment.
Is about how the management, our pairs and ourselves received that change of perspective.

State of the Art
Ten months ago, we started working in a new middle-to-big size project (about 40 people). This people were distributed in different teams. There was a functional team, a testing team, and two developer teams; a .NET and a Java team (we were on the Java team).
In spite of being a certified CMM company, there was no developer "good practices" document or some sort of recommendations to get the work well done.

So, we defined the bases of the architecture (an up to front design) and we begin to build the first Use Cases.
We started to notice some sort of bad things. Just a few people or no one were making unit test for the functionality they were building, and even worse, the people were making changes to the code but they didn´t change that things on our unit test (refactoring?), so they were also breaking the build.
At the same time, developers weren´t talking to each others, so they were working on same things (e.g. exception mechanism, logger mechanism, etc)
We were far away from home, the team didn´t know what a unit test was, what refactoring was, what a build was, we had poor communication (inside the team and between the teams), no collaboration at all, and a long way to go trhougth.

Our First Stone, Automated Test
At the beginning of the project, no one was making unit test, and we were breaking the few that we´ve got. So, we needed to explain to people that tests weren´t just a part of the application, but they were the application, just like code of the persistence mechanism was.
First of all, we explained what unit testing was, which its benefits were (use code example, refactor, etc) and we build a little mechanism to support our tests.
Obviously, no one begun to test from one day to another, we´ve got to demonstrate people that testing was a good thing. That was our challenge, now we needed an opportunity.

On the second month, the requirements were vague and so the uses cases, we were changing the code every day. Every time that one developer change something, that change broke some other functionality. But, if we have a test for every functionality, then we could change something in our code, run the test and verify that nothing went wrong. That was our opportunity to show the world that testing was a good thing, and we did it!.

Just about a month later, we were testing. They were integration test, not unit test, we didn´t mock anything, our test hit the database, the file system, we were making Test Last, but at least we were testing.
We were happy for a while, but a soon as we build more and more integration test, the time to run the whole suite was going up. Finally we needed about 40 minutes to run all the suite to commit a change!

Conclusions
When we started, nobody knew how to get things done, there were just a Senior developer, a lot of Junior developers, and no managment support. We had a lot of problems, we had to choose one and solve it.
If we could automate out test, we would go further (Test First, TDD, Refactoring, CI just for named a few). as we can see in the following picture.

We started to automate our test, that was the first stone, now we could build a new world over it, and that was our next goal.