I have worked with SharePoint for seven years now, all the way back to 2005 when I started with SharePoint 2003 after moving off of Microsoft Content Management Server. For much of this time the projects I worked on were run either as waterfall or in an operations & maintenance (O&M)/time & materials (T&M) fashion.
Fast forward to 2011. I moved to a new job at Hewlett-Packard Enterprise Services over the summer and in the fall began my first SharePoint project that fully used the Agile Scrum methodology. Most of our project team was new to Scrum as well, so we all dove into it together for the first time.
Agile is a framework that has a few different official methodologies you can choose from. The basic tenant is to focus on making working products in an iterative fashion and adjusting to change without being stifled by rigid process. This is emphasized by the Agile Manifesto. That does not mean we forget about process, planning, and documentation. We still do those things. It is about balance.
Scrum is one of the most popular agile methodologies, if not the most popular, especially for software development. We use the concept of a “time box” to focus on shorter periods of work while keeping an eye on the overall goal. The Scrum Alliance has a nice, quick intro to Scrum that summarizes it quite well: The Scrum Framework in 30 Seconds.
We are now on sprint 5 of our SharePoint custom development project using Scrum and I am totally into it. The methods are working to give us focus, keep us on track with the most important priorities, and provide transparency to everyone involved in the process including the stakeholders and product owner (customer). This makes a lot of sense, and is how I always tried to work on a smaller scale on previous projects. This just formalizes the flexible yet defined process for everyone involved. That statement probably makes more sense if you have already done an Agile project. If not, read the links below and you too may get indoctrinated.
So what does this have to do with SharePoint, besides the fact that I’m working on a SharePoint project? I plan to break down different areas of Scrum for SharePoint over a few blog posts, which will likely include:
- How the product backlog handles SharePoint configuration and customization
- Integration between the development, requirements & testing teams and the stakeholders & product owner
- When does overall SharePoint architecture fit into the picture?
- What about infrastructure?
- How to address technical and graphic design
- Technical Debt: Focus on what must be done now but also track what should be done later
- Development process, deployments, and continuous integration (aka Application Lifecycle Management)
- More, more, more!
I need to emphasize that there is not just one way to do Agile Scrum for SharePoint, or any project for that matter. I will talk about how we’ve done it and how I have seen other projects do it. The point is, your process depends on your team and your timeline and your goals. It is just a framework and methodology, not a prescriptive guidebook. Consistency is the key. So no matter what you choose to do, you should follow your process consistently. Agile is not a prescription for anarchy. It is a set of suggestions that can be formed together to create your successful process.
Also, I can’t start a discussion about Scrum for SharePoint without a shout out to Andrew Woodward, 21Apps, and their 21Scrum project.
To find out more about Agile and Scrum check out:
- Agile
- Scrum
- Agile Manifesto
- The Scrum Framework in 30 Seconds
- Glossary of Scrum Terms
- 21Scrum – Scrum for SharePoint
The next article in the series Scrum for SharePoint: Article Backlog is up!
Posts
