That’s right, folks:  Yours truly got word earlier this month that his proposal for a session was accepted for delivery on August 6, 2008 at 16:00h here in Toronto on the topic of post-secondary agile course availability.  My topic is tentatively titled, “Who's Teaching Best Practices? A review of Canadian CS/SE curriculums and how to improve integration of agile/best practices” and is based in part on my two-part post series from September 2007 on the same topic.

I’m both surprised and excited to have been given approval becuase I really took a drubbing from some proposal reviewers who weren’t happy with my idea at all.  I wasn’t exactly sure what was motivating the dissent, but the effect was essentially like tossing cold water on the whole premise of questioning the curriculum development process for Computer Science and Software Engineering schools.  Given the philosophy of transparency that is supposed to underpin agile practices, it seemed contradictory to be stonewalled on this basis. 

In any event, enough reviewers must have agreed to get me the pass for my 60 minute session which will be broken into two parts, with the first detailing my findings from the blog entries, and the next engaging participants to develop their own ideas on how agile/iterative/lean practices can be better positioned in Computer Science/Software Engineering schools.

See my original series that inspired the session here:  Part 1, Part 2  And be sure to see the Agile 2008 Conference Site for more information on other speakers, stages and events.

See you there!

Just finished reading a brilliant 5–part series of posts by Aussie SharePoint consultant, Paul Culmsee, that lays bare what many of us intuitively know about why so many MOSS projects meet with failure:  It’s not the technology, it’s the people.

Paul dilutes the principal causes of SharePoint project failure into several key areas:

1. Instead of being the solution to a problem, SharePoint actually exacerbates the problem domain because it is a complex product that has come to mean many things to many people;
2. As a result of 1), SharePoint projects engender what has come to be known as “wicked problems”, or those that have no real end-game or winning scenario.  They’re almost always characterized by some significant setback or loss or disappointment.
3. Often, project managers, executive sponsors, IT and developers enter into implementations by grossly underestimating scope and underlying physical infrastructure requirements, governance measures, information architecture, and the potential impact to existing systems.  The resulting conflagration often doesn’t blossom immediately, but when it does…
4. SharePoint has become a victim of its own success, with unfortunate abuses of acronyms and terminology around its features and usage scenarios.  Often, this is done at the hands of pre-sales folks.

In almost all of my SharePoint projects I have encountered the issues and wicked problems that Paul describes – some of them lamentably brought about by too much planning and analysis paralysis (BDUF/waterfall) and some by just rushing in a “yeah, yeah, yeah I get it, we don’t need to talk to users let’s just install the thing quick fast and roll it out NOW we’ll worry about content types and site columns and governance later” fashion.

I think Paul makes a lot of solid observations in the series, perhaps none more salient than the fact that because SharePoint is so expansive and so new, it is an immature product (much like Active Directory was in 2000).  Thus, it’s really premature to be speaking in terms of recommended or best practices with respect to the product since very few people on Earth have been running it long enough or extensively enough to generate the necessary corpus of empirical practices.

Do take the time to read Paul’s blog – it’s chock-full of pragmatic SharePoint goodness borne out of practical experience.  Start with Part 1 of his Why do SharePoint Projects Fail? series – I guarantee you’ll be laughing hysterically and nodding violently in agreement with almost everything he says.