Agile Checklist Part 2
Decide on which aspects of agile you will apply to the project.
Note that the impact will vary very much depending on this.
Aspects like pair programming or test driven design can be applied locally, whereas continuous integration, for example, has a broad impact on the project, and may require the participation and cooperation of all contributing toward the project.

As a general rule it is difficult if not impossible to use a mixed agile & waterfall approach.

Agile Checklist Part 1
I will be adding notes an agile projects on an occasional basis for all considering how to go about initiating an agile software project.

Make sure you have the support of project and line management.

Often some developers are keen to go agile while others are reserved. You can't do it alone (unless your software requires no changed or new interfaces)! And unless you have the go ahead from management you will find them making requirements you cannot fulfill, e.g. you cannot declare an overall "code ready" at the time they will be expecting when you have several iterations including unit and integration testing.

It is also necessary to define in what sense your project is agile since there are various approaches and degrees to agile, and to ensure management has the same understanding. I often find there are misconceptions such as: agile allows for continuously changing requirements. Also note that agile requires a high degree of transparency. You may find that management does not feel easy about too much transparency within the project!

Puzzle resolved
Just in case anyone's wondering what the solution to last Fridays puzzle was: the bug is that the interface is missing a virtual destructor!
The compiler generates a default non-virtual destructor. That means when delete is called on a pointer who's type is BuggyInterface* only that class's destructor is called, not that of the derived class.
Any heap memory possibly allocated in the derived class that the destructor might free will remain allocated - i.e. a memory leak!

Who writes the mocks?
Most projects I've come across use unit-testing as a method to verify code quality. A common issue is that mock objects are needed to satisfy the external dependancies a component has, and possibly to simulate the behaviour of these external components. I have come across two strategies as to who writes the mocks: a) either the one who needs the mock, or b) the one who owns the component you want to mock.

The problem with former option is it can mean a lot of additional work maintaining a mock such that it remains conform to the interface of the component you want to mock. What's more you have no control over that interface, and it may require you to maintain your mock if it is a java interface or it contains C++ pure virtual methods. Another point is that other component owners may also require mocks for that same component, so the danger is a multitude of mocks get created, sometimes badly maintained.

The option b) sounds much better but the problem here is motivating a component owner to maintain a mock of his component that is usually of no use to himself. I have found that as project deadlines becomes more challenging this approach gets more and more difficult to enforce.

Of course, if you have to mock 3rd party code, then there is no choice.

I'd be interested whether there are any other workable approaches or experiences anyone has come across.

Puzzle
A bug that crops up time and time again:

class BuggyInterface
{
public:
virtual void interfaceMethod();
}

class ImplementsBuggyInterface: public BuggyInterface
{
public:
ImplementsBuggyInterface();
~ImplementsBuggyInterface();
void interfaceMethod();
}

BuggyInterface* p = new ImplementsBuggyInterface();
delete p;


Guess what's wrong!