Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Sounds pretty simple.  I notice that there are twelve Agile principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.

The agile principles are interesting, because in a lot of ways I can see advocates of other methodologies (BDUF) saying the believe in the same thing.

Asking amongst some peers, and there didn’t really seem to be a concise definition of Agile and what you need to do to call yourself.  I’ve seen some places that will suggest that they are Agile because they stand up at meetings (or a manager wanders around once a day), avoid documentation, and have a meeting every three or four weeks that they call a “retrospective”.  So, does anybody care to offer up their thoughts on what one needs to do to be considered Agile?  I have my own thoughts, but figured I’d save them for a later blog post.

For a greenfield project, don’t use the database someone hands off to you

The project I was working on was greenfield – almost.  The business analyst spent a lot of time and effort gathering requirements, and this spilled out into him creating the database for us.  On the surface, to most people, this seems like a good idea.  In reality, I’d rate it slightly above mixing nuts and chewing gum for a snack.  Why do I say that?  Because, the database schema that was handed to me was highly normalized and (so I was told) optimized for reporting purposes – at the expense of the application.  This application was more like an order-entry system, with snapshots of the data at points in time being very relevant.  This "…optimization for reporting…" cause a lot of unnecessary work on the part of us poor developers.

The argument of "…the schema is this way to make reporting easy…" doesn’t fly with me.  First off, we don’t have any reports defined.  In fact, reporting wasn’t within the scope of this project.  So, why are we worrying about it?  Secondly, if a certain schema was necessary for reporting, then that is where views and stored procedures come into play. 

I very much wish that we would have said, "Thanks for the effort, but we will create the schema we need to delivery the product.". 

Lesson learned for future projects:  Greenfield projects should not accept databases designed by someone who has no stake/input/authority on the application architecture.

People are inherently obsessed with local optimization at the expense of the whole.

One example of this I’ve already quoted:  effort was expended to create an academically pure database that would be good for reporting.  This local optima cost the project in the whole, because it incurred extra effort in developing the application.

A second example in support of this claim is a touch more elusive.  I witnessed a fair bit of "requirements dickering".  Rather than looking at the project as a whole and trying to get the most bang for the buck (this project had a hard limit on dollars, but not on time), a lot of time was spent on arguing requirements.  There was a perception that unless everything that was in the requirements document was done, "professionally" tested, and properly signed off, the application as a whole was not useful.  It seemed that everything was important and had to be done.  This obsession with getting everything done was, in my opinion, getting in the way of getting things of value done.

To misquote Napoleon:  he who defends everywhere defends nowhere.

Lesson learned for future projects:  Really to me, this experience did provide more anecdotal evidence supporting the Agile Manifesto and agile techniques.  Being a lowly contract developer, I was in no position to dictate priority or importance of work.  I’m kind of used to that as a consultant.  My opinion and advice was provided and the project leadership did with it what the wanted.  However, the process did open my eyes a lot.  I hope that if I ever find myself running the show in similar circumstances, I have the wisdom and the patience to see the big picture, and not the black and white words of some document written almost a year ago.