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.

SharePoint - Public vs. Private Site

An overview of public vs private sites.

Public Sites – A site referred to as public will by default be available in a read only format to all users whom have access to the said Internet or Intranet site. The home page of the Intranet is an example of a public site.

Private Sites – A site referred to as private will only be available to those users whom have been granted access. Such sites will contain team collaboration information which should be shared only to applicable users. An example of a private site would be an IT Private Site which would contain content and diagrams which only IT team members would be able to see and collaborate on.

Overall, a good rule of thumb would be to have a private site created and available for applicable team members to create master content in (example as a .doc or .docx format) – then if such content is to be viewed on a public site – it should be created as a .pdf then uploaded/moved to a public site. This way, master documents are kept on the private site – then only posted in a .pdf format to a public site when content is to be shared to a wider audience.