I’ve been reviewing Project 21 and how it fits in relationship to Agile and other methodologies. The theme of Project 21 can be broken up into three segments Analyse, Design and Construct. Repeat until the project is complete. These segments are not mutually exclusive, but in a self-assembling team they would have different, but overlapping primary participants.

I didn’t originally set out to structure the methodology this way, but then I realised that all my analysis was conceptul, which made that one simple. Design started as Logical and Physical Design, which are always next to each other, so that’s the design segment. Often the same team members are involved with logical and physical design, and it can be regarded as a continuum joining analysis to construction. Contruction is the goal, and testing has to be part of that.

For the one-man team this is simple. Think about what you are about to do, then how you are going to do it and then do it. Repeat until complete.

The mechanism for joining all of this together is the model, the conceptual model is the home of the end users vision of what the system will achive, curated by team members, so that it is realistic.

The design model is the common model against which the project is constructed, it should be minimalistic and descibe sufficient features to tie conceptual thinking and construction together.

I’m tempted to use the term Domain Model as a unifying model that rules everything.

I’ve decided it’s time to spend a little more time on Project 21. I’ve recently been involved in a development project and I feel better qualified to write on this subject from a contemporary viewpoint, so I will. I’m also reading Scott Ambler’s fine book ‘Disciplined Agile Delivery’. I thought that as I went through the book that I would see how Project 21 handles the various aspect of Agile.

Project 21 in principally designed as a lightweight methodology for small multi-disciplinary teams, so by its nature it should be Agile.