Polymorphic Rants

Friday, 20th of November 2009, the 6th Italian Agile Day will be held in Bologna.

It’s a great opportunity to share experiences and practices, learn, discuss and meet other praticioners part of the  Agile community…and moreover it’s free

I’ll see you there !

The beginning of a project is always a hectic period where several things have to be put in place in order to be able to start the actual development from a solid position.

Interestingly enough, I see that what is important to have ready for ThoughtWorkers most of the time is not what has to be ready for other people.

Given that obviously every project is different and deserve specific attention, here is my list of things that has to be ready before the kick off of iteration 1.

Infrastructure

A repository, a Continuos Integration Environment with Cruise (or suitable alternatives) installed and working, a QA environment where we can deploy every successful build whenever we want, a basic build script (i.e. build/run tests/package). Pairing boxes, each one with exactly the same configuration.

Architecture

Just identify the core services/components, there’s no need to go into detail for each one at this time of the project. If we identify what is the main responsibility of a service is good enough for now, the details will be discovered later in the project. If we can easily identify the way services will communicate (web service ? message broker ?) good, if not through good OO principles we can abstract the low level mechanism and reduce the cost of change later, deferring the final decision to the point in the project where we have more understanding of the technological constraints.

Patterns

Pairing and frequent pair rotation will help in spreading the knowledge of the approach to solve specific problems and in maintaining consistency throughout the code base, so most of the time there is no need of defining a sort of “project dictionary” of valid patterns at day 1.
If we’re introducing new approaches to solve a specific problem, it’s important to highlight pros and cons of the approach so that people know what they are doing once pairing.

Most of the time these are probably enough to start Iteration 1.

All the other decisions can (and sometimes should…) be deferred to a later stage.

In a lot of companies  the productivity  of a QA is measured through the number of defects she raised: the  more defects she finds, the harder she works, therefore the better she is.

This approach has an interesting corollary:  if you have really good QAs you don’t have good developers. If your QAs are finding a lot of defects this means that your developers are quite poor and are regularly introducing defects in the code base.

This approach isn’t obviously team oriented: QA and Development are seen as two separate and independent entities that interact through a specific contract.

If we truly believe in collaboration the most important productivity metrics are not related to a specific role/set of skills but to the team capability of deliver quality software in time and in budget.

We need to ask ourselves why the defects are finding their way into the application deployed in the live environment (incomplete acceptance criteria ? not enough analysis or understanding of the domain ? gap in the test suite ?), and fix the issue as a team, not just using that number as the boundary between two streams of work.

Walking in an office and just looking around for 10 minutes is enough to have a feelingof the level of communication in the environment.

When:

• co-located people communicate mainly via IMs, mails, or comments on online collaborative tools instead of face-to-face conversation
• a heavyweight tool is the preferred way for driving the work flow instead of using it only for backup and tracking
• on the whiteboard you can read the outcomes of the retrospective of 7 months before

There’s definitively something wrong.

What about your team ? How many of the above bullet points are you ticking off ?

Here on InfoQ some interesting thoughts around Seniority and Authority in an Agile team.

For the third year the European Summer School of Agile Programming(Essap) is a great opportunity to learn more about Agile Methodologies.

Here the website of the school: check it out.

The fifth edition of the Agile Day has been announced.

As usual it’s an incredible opportunity to talk with a lot fo smart people of everything is related to agile methodologies; either if you are an experienced agile pratictioner or you are just starting knowing this world this is an appointment you can’t miss !!