Presented by Stephen Forte again (second time inside of a single day!), this final session at Tech-Ed was a review of what SCRUM is, how it's working for people and then it turned over to mass debate.
Again, we find religious arguments coming to a head in this scenario between the agile purists and the more pragmatic fixed price bid guys.
Personally, I'm somewhere in between, where, given the opportunity to do a time + materials project using SCRUM, I would prefer to, but often we must be realistic and offer fixed price contracts to clients, even though doing so is difficult because up front design is always wrong and this is why SCRUM rejects this outright.
(Saying this though, even in fixed price bid contracts, one can still apply and benefit from the principles of SCRUM (backlogs, sprints, daily scrums, business owner involvement etc). Doing so will just expose problems earlier, which is a positive thing.)
Big design up front wise - the minute a specification is published it starts to go out of date and becomes incorrect. Never have I (nor had anyone else in the room) seen a specification written before a project and been able to go back and compare the delivery with the original specification to find an exact match.
These differences, errors and omissions add time to the project, but in relation to total project time, not just in relation to the slippage felt by the initial mistake. For example, If I have a 4 month project and during month 1, I find slippage of 1 week, does my project length get extended by 1 week only?
No - it gets extended as a factor of the time so far consumed and remaining.
My project was 4 months, and in the first month I found an omission that has cost me 25% of the time I've spent so far, so it's a reasonable assumption that I'll find a similar quantity of omissions in the remaining development, so my overall increase isn't 1 week, it's 1 month - this is a fact that causes many development projects to be seen as failures that have gone drastically over time and over budget.
This principle, which has been proven many times was written by Fred Brookes in an essay back in 1975 and it is as valid today as it was back then. I recommend reading the book: mythical man month for more information on this and many other principles - including the famous Brookes Law - adding more manpower to a late project makes it later.
Anyway, back to the session - it was highly enjoyable and despite the presence of significant dogma - I think everyone was able to learn something new from each other and from the presenter.