Project management with Microsoft Office SharePoint Server

This post was originally published here.

Having used Team System in the past, I’ve been trying to wrap my head around using Team System for work items in our group.  We’re using Team System exclusively for source control, but there’s a lot more functionality available to use.  At the heart of a Team System project is the process template, which creates the work item templates, reports, and the team portal page.  The problem I’m seeing is that our Team Project, scoped for source control, spans many groups, many internal projects, many versions, and many global teams.  We have Core, Back End, Personalization, Front End, B2B, etc. applications.  We have 2.1, 2.1.5, and 2.2 versions.  We have Global, Asia Pacific, US/CA, Latin America, and Europe regions.  All of these different groups, concerns, and project requirements are under a single Team Project.  How are we supposed to create a single process template that could possibly work?

What Team System can give us

In my last project, we used Scrum as our development process, and Scrum for Team System as our process template.  For those unfamiliar with Scrum, it is a lightweight, incremental and iterative development process that breaks the development cycle into iterations called “sprints”.  Each sprint is timeboxed, such that no extra work can be assigned nor can the length of the iteration be changed during the sprint.  Time and requirements are fixed during the sprint.

All development we did was driven off of requirements that were defined and managed from Team System.  When we checked in code, we associated the check-in with a work item.  When we ran builds, we could see what checkins were part of that build, what comments were available, and what work items were worked on for that build.  Additionally, we no longer needed any status meetings, since individual team members would update the work remaining of their work items every day.  Burndown charts told us (and management) if we were on track or not.  Reports told us at any given time:

• Progress against the work committed for the current sprint
  • Progress against the work committed for the current release
    • Status of individual features or user stories (not started, in progress, ready for test, complete)
      • Hierarchical composition of features and tasks, with effort and work remaining</ul> Call me crazy, but I think it’s perfectly reasonable to let the team members be responsible for keeping the status of their tasks up to date and not the project manager.  All of this information was available at any time, in real time, and always represented the “truth” of the project status.

      Current issues

      The problem with our current layout for our Team Project is that it spans so many teams, so many projects, and so many geographical groups.  For a process template to be effective for this topology, it would need to be

      • Generalized so we don’t pigeon hole all teams into a monolithic process
        • Flexible to handle different process needs and schedules
          • Extensible to allow modifications and additions</ul> I’m a big fan of self-organizing teams.  We have a lot of intelligent people on our team, we should be able to decide how best to work.  Process templates are pretty much set in stone once the Team Project is created, so I don’t see a whole lot of value applying a process template to the topology we have now in our source control.  With Scrum, we had a Sprint Retrospective after each sprint to look at improving our process.  This regular feedback would be tough, if not impossible to act on if we have to approve changes across a global team.

          The SharePoint solution

          I recently ran across another solution to this problem that used SharePoint.  Instead of Team System to manage the Product Backlog and Sprint Backlog, you can use SharePoint lists to house these artifacts.  You can still use Excel for reports, and SharePoint includes a powerful search feature that Team System doesn’t have.  What you would lose is the ability to link to work items as you can in Team System.  But without completely changing the topology of our Team Projects to project-based, I just can’t see us being able to take advantage of the process templates in Team System.  SharePoint also gives you custom views on top of your data, and those look to be a little bit easier to use than the custom queries and reports in Team System.

          The cool thing about a SharePoint solution is that it wouldn’t be tied to Team System, so each team could manage their own team project however they wish.  You give up some in the integration that Team System provides, but you can gain some by allowing each team to take responsibility for their process.  If some teams have well-defined and mature development processes, some meta-elements could eventually be developed into a framework for a process template (I’m a big proponent of harvested frameworks).  Since the reality is we can’t do whole team together, SharePoint is a great solution to enable collaborative, communicative teams.