Loss of Molecular viewpoint that occurs within a Traditional methodology is really something that cannot be avoided. By it’s very structure the Traditional methodology looks at technical stakeholders (Developers, Office Personnel, Other Low-Mid level persons who will be actually using the products) as ‘Specification-Compiling-Robots’. Well perhaps that’s a bit too harsh, how about ‘Specification Defining Persons’, SDPs for short. SDPs are simply the human variable within a Traditional methodology’s need to define what it must accomplish, but they aren’t approached necessarily as “human”, hence the aforementioned ‘robot’ terminology. Due to the overwhelming need for the Traditional methodology to exhaustively define the specifications of a deliverable, well before even beginning development, (well before even fully understanding what is being built); it tends to seek to extract specifications from these stakeholders and clump them all together. So now some may reply, “Well obviously we need specifications, what are you suggesting we do, read their minds!?”. In any other discipline within IS I would be more than happy to entertain the philosophical gymnastics surrounding the possibility of creating some mind-guessing super computer, used solely for the fabrication of perfect project plans based upon specifications tapped from the minds of unaware stakeholders; but I digress. For the reality is that the mind-set here is just completely wrong. Project management is people management. In no way is it being suggested that specifications are irrelevant, nor is it to be understood that the Traditional approach is the only approach that relies upon them. However, the Traditional approach is horrible wrong in how it goes about gathering specifications; with what I like to call the ‘One-Night-Stand’.

The ‘One-Night-Stand’. No it’s not a passionate night of champagne, fruit and glitter with the project manager (Remember to always disclose ALL intimate relationships to HR); it’s the Traditional methodology’s way of handling specifications, all in ‘one night’. It basically works like this:

1. Research who knows what
2. Categorize each person based upon knowledge area and level of knowledge
3. Re-categorize each person again based upon their vested interests
4. Run a meeting to pick their brains of all that knowledge
5. Using what you’ve picked build a set of specifications for the scope of the project
6. Run another meeting to finalize and ‘sign-off’ on specifications
7. 7.Manage the project to the ‘signed-off’ scope

This presents itself as slightly more complicated then it really is; when simply put, the specifications are acquired from the SDPs, then organized nice and neatly, then verified by the SDPs, then they become a project artifact that the PM uses to control the project.  That’s it. End of story. The traditional methodology is a ‘One-Night-Stand’ and only cares about the SDPs for as long as it takes to squeeze every drop of specifications out of them. Enter Agile, the ‘Several-Night-Servant’. Now doesn’t that just sound more fun?

Agile, the ‘Several-Night-Servant’, thinks that SDPs are more then, well, SDPs. Agile views the SDPs as people; people who know things, but also people who may have forgotten things, or people who may have different needs in the future. The Agile methodology thinks, “If I want to satisfy my stakeholders, I need to spend time with them, get to know them, and develop an intimate relationship with them and their work.” Unlike the Traditional methodology, Agile isn’t interested in just a ‘One-Night-Stand’, it’s in for the long haul, in fact, the Agile approach wants to have as much time with the stakeholders as possible to review where the project is and receive feedback to refactor where the project is headed, along with making sure that what is being built is what will satisfy their needs. It basically works like this:

1. Research who knows what

2. Categorize each person based upon knowledge area and level of knowledge

3. Re-categorize each person again based upon their vested interests

4. Run a meeting to pick their brains of all that knowledge; build a set of specifications for the scope of the project and select an area of functionality/deliverability to address first

5. As developers work have them meet with stakeholders (within the particular area of functionality that they are working) to review progress and assess satisfaction

   1. If the functionality is complete, and the stakeholder is satisfied, move on to the next function/deliverable

   2. If the functionality has changed (No longer needed, Major change, Minor change) have developer refactor the functionality, rebuild and re-meet with the stakeholders to again review progress and assess satisfaction

6. Continue until project is completed and all stakeholders have been fully satisfied

One would think it’s safe to assume all stakeholders would prefer to be satisfied rather than have their brains picked and harvested. Yet still, day in and day out the Traditional methodology rolls on, delivering products that are 60-80% satisfying; all-the-while, Agile is leaving all of its stakeholders thoroughly pleasured at 100% satisfaction; that is, if conducted and concluded correctly. After all, the greatest methodology means nothing if you don’t have a successful completion, right!?