One of the issues with with dogfooding your own projects to accelerate development might be the lack of control and feedback from the specifications and requirements process. To try and mitigate this effect, automated testing should be done, that is specification, feature and behavioural testing. Call it what you will, but the basic idea is to get a common understanding between the stakeholder, project owner and developer to understand what is being built and to write automated tests collectively to ensure that it is being delivered.
Team meetings can be both productive and counter productive as most people find. If they are well structured with a purpose and goal then a lot can be achieved (most of the time).
For explorartory meetings, it’s probably okay to have some time set aside for some free and open discussions. Once a goal has been agreed upon, it’s probably a good idea to focus on it more and steer the discussion to try and deliver on the goal.
Waterfall methods seem to work well for smallish projects that are well defined and well understood. At least from my own experiences of putting things together, but realistically to think of all possible scenarios and to write up all the possible solutions to the problem seems a little bit wacky. To also assume that the requirements process has captured requirements that won’t change close the end of the project is also a little unreasonable or unrealistic, this would be especially true on a project that is planned to run for a few years with fairly substantial goals in an ever changing research and development environment.
Apart from the obvious unit testing code which could be fun trying to convince a team to use. There are things known as ‘Continuous Integration’ processes and servers. The basic idea is to continually build and test your product automatically and report on successful and failed builds.
I’ve known about this methodology for long time now but I’ve never bothered to install a CI server since it was always for myself.
Having worked in a number of cross institutional projects in the past has lead me to always be weary about how to interact with people. Often it’s the lack of co-ordination and communication that seems to be the killer. Parts of the team would seem to not know what other parts of the team are doing and thus either deviate from the master plan or duplicate work.
Gathering requirements for a project is always fun, translating the requirements for a developer to create the end product is even more fun, it often can lead to ‘chinese whispers’ where things just get miscommunicated and misunderstood.