I was recently preparing a presentation for a Chicago SharePoint Saturday. As I built out my slides explaining some O365 DevOps best practice it struck me that an Agile methodology could be the only viable methodology to deliver and maintain SharePoint Online projects. Here’s why…
At Perficient we have embraced SCRUM for many SharePoint projects and it has proven to be very successful. I took the SCRUM Master Course and certification to solidify my understanding of SCRUM. I recall the tutor saying that the largest part of adopting Agile is to think in an agile way. Quite simply I have modified the way I think about projects and I think this has helped me lead projects in the cloud.
To contrast, I began to think about how hard it would be to deliver SharePoint Online projects using a more traditional waterfall methodology. When you consider the ‘Evergreen’ service and how quickly we are seeing new features appear it’s a paradigm shift in my field of work as a SharePoint Architect.
I have made it part of my weekly routine to check the Office 365 public roadmap to assess features being rolled out as well as those on the horizon. This helps me understand, from a feature perspective, what I need to keep a close eye on in coming weeks.
O365 Public Roadmap
In conjunction I also ensure that our development and QA tenants are signed up for ‘First Release’ (under O365 Service Settings). This enables me to see the features being rolled out at least two weeks prior to general availability and the change hitting our production tenants. This gives first sight of potential issues as well as identifying new feature opportunities.
O365 First Release
Whether it’s the desire to work with a new feature or the need to respond to a change you’ll have a minimum of two weeks to respond. There is no longer the option to hold off a service pack or ‘hang five’ on that security update as we may have done on-premises.
How would your project handle the need to change, test and deploy within a two week period? Most likely, if you are following a traditional waterfall approach, this will be very difficult. If the service changes during a Build phase, how would you change direction and redesign? If you are a consultant, how would this affect scope and budget? What about your release cycle? Is it frequent enough to keep pace?
Our SharePoint Online SCRUM projects are typically running on a 1-2 week Sprint cycle. We usually start out with a 2 week cycle but then accelerate to a 1 week during a stabilization phase, when we do less new development and enter early support and maintenance. This enables us to achieve 1-2 releases during this critical window and keep pace with the service.
Is your methodology agile enough to keep pace in the cloud?
