Using SharePoint Blog Sites for Team Collaboration
About a year and a half ago, Mario Rodriguez and I were looking for an idea to help consolidate all of the planning for the feature work that was underway for the 2010 release. Recently, we started migrating some of our old blog content, and I thought it would be interesting to share our experiences now that we’ve been successfully using these blogs for some time.
Previously we were using a space on our divisional SharePoint site to store documents, but over time, docs became fragmented. In some cases, PMs were putting docs in a PM folder, while developers and testers had their own dev/test team folder and subfolders for their feature areas. Some of the feature crews had their own folders with nested PM, dev, and test folders, and still others had documents under a feature area folder (i.e. VC, WIT, Build) with nested PM/Dev/Test folders. Needless to say, this was a system that was becoming increasingly difficult to manage with each additional feature crew, and with dozens of feature crews on the horizon, we needed a new solution fast.
The root of our problem of managing docs was that we had no standard for the top level of organization. Since we center our development around the feature crew model, it seemed logical to mirror this structure in our document hierarchy. However, there was still a need for team documents that didn’t necessarily belong to a single feature crew (i.e. the client side threat model), so we would need a team wide document store as well. It seemed that the structure that made sense was a Version Control team document folder, with child folders for each individual feature crew.
In addition to better organizing our documents, we found that there were a lot of announcements and meeting notes that we wanted to share with the entire team. What we really needed was an entire sub site for the version control team – thus our Version Control team SharePoint blog was created. As we started to move team docs to this new site, we realized that each feature crew would also have announcements and meeting notes that would be great to share. This led us to the final model that we’ve been using ever since – one blog site for the entire VC team, and sub-blog sites for each new feature crew.
The benefits of the one-site-per-feature-crew model are that each developer and tester on the team now have one site to go to for everything related to the current feature crew on which they are working. All of the specs, design documents, and test plans are centrally located for a given crew, and right next to the docs are all of the meeting notes tracking decisions made over time. Using a blog format for the notes also has the benefit of the most recent decisions being most prominent, showing the evolution of the feature design over time.
Overall, the system has worked well for our team. The developers and testers have had an easy time managing their documents and tracking decisions, and the dev and test leads can quickly browse the latest posts for the feature crew blogs to see what’s been happening for any given crew. As a PM, I have a few more sites to keep track of, but if I can keep the dev and test teams happy, it makes my life a whole lot easier :)