Project Methodology - Waterfall vs. Agile for SharePoint Projects

In regard to project management methodologies and SharePoint – for a long time I utilized a pure Waterfall methodology where requirement analysis, system design, implementation, testing, deployment and maintenance was done. Since a large majority of the SharePoint work I’ve done to date involved migrating content from one system to another or from one SharePoint version to another – this methodology appeared to work well in these projects – however pros and cons were evident. Essentially since content always needed to be reviewed the requirement was well known it was move content from this SharePoint location/version to this SharePoint location/version. At the system design phase – the Waterfall and SharePoint do work a majority of the time because it is known what the said systems base will be utilizing. The only aspects from a systems standpoint is that from one version to another – different features typically needed to be turned on to support needed functionality. Great example being site publishing. Testing using Waterfall – seemed to always be slow as test scripts either needed to be written or a load test needed created in the designated application (example: Load-runner, Team Foundation Server, Stress Stimulus etc.) Additionally, deploying using Waterfall seemed to produce a fair amount of documents surrounding lists of various items that needed turned on, configured for, migrated, moved etc. Then maintenance using Waterfall – really always seemed to leave a lot to be desired as guess work into what was really being asked for a lot of times – resulted in sites and subsites that didn’t meet user’s requirements and thus – had to be scrapped.  

Now coming to age – it appears SharePoint and an agile project methodology – work well. The notion of creating work that is broken down into 5, 10, 15, 30, 60, 90 day sprints is ideal.  For the larger work an epic – usually work that spans a quarter (or 90 days) works well for SharePoint because typically this is how long the complex world of SharePoint to migrate a site or create it – spans if all the bells and whistles of content analysis, design, graphics, training and testing are to occur.

An example of an epic maybe: [SharePoint 2016 – IT Site]

A feature which would be a core item that needs to be included in the project and associated with this epic maybe: [SharePoint 2016 – IT Site] – Create IT site

Stories are core working pieces that need to be built and are part of a feature – so example items are:

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT project list page

Tasks will then appear under each story so in this example case these would be:

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Therefore putting this down on paper with the epic/feature/story/task – the project mapped out would look as such where the indenting depicts where the item fits in regard to this methodology:

[SharePoint 2016 – IT Site]

[SharePoint 2016 – IT Site] – Create IT site

[SharePoint 2016 – IT Site] – Create IT homepage landing

[SharePoint 2016 – IT Site] – Create IT homepage graphics

[SharePoint 2016 – IT Site] – Create IT homepage content

[SharePoint 2016 – IT Site] – Create IT calendar page

[SharePoint 2016 – IT Site] – Create IT calendar permissioned to only managers

[SharePoint 2016 – IT Site] – Create IT contact list page

[SharePoint 2016 – IT Site] – Create IT contact list permissioned to only IT employees

[SharePoint 2016 – IT Site] – Create IT project list page

 [SharePoint 2016 – IT Site] – Create IT project list permissioned only to project managers

Thus, it’s easy to see why the Agile methodology lends itself to SharePoint in a much broader way – as features, stories and tasks can be created as the project itself evolves. Since SharePoint lends itself to creating sites of business value – by using an Agile methodology users will have real working sites with the needed requirements more quickly and can therefore, change items as needed as the sprint progresses. Because of this – I’ve found that Agile is a better project methodology choice for SharePoint projects then Waterfall.