Sharepoint Installation

This blog post is probably a figment of the writer's imagination. Read at your own risk.

Background

In fall semester, the SQUARE Root team's tracking was inadequate. The team was tracking a bunch of stuff, but it was not getting the value for it. Tracking was done on excel sheets on the shared folder and combined using scripts. Therefore, when a team member wanted to put his/her time on the timecard, s/he had to sign into the the VPN, remote desktop into the server, and then put in the time. This was tedious and boring. Also the team was not accustomed to tracking As a result, aggregating the data at the end of iterations was difficult, and the team could not draw any conclusions from it.


A New Hope

At the beginning of Spring, I installed sharepoint to tackle with the tracking problem. Sharepoint provides a central repository for tracking data. The user interface of Sharepoint was similar to Microsoft Excel, and so the team did not have to learn anything new.

There was still some scepticism regarding Sharepoint's ability, probably because it was not clear at first what would be documented in the wiki vs. what would be in Sharepoint. However, we resolved these pretty quickly.

We were able to trace from the milestones set at the planning meetings to the individual tasks completed by the team. Therefore, we were also able to see the team's progress on a week to week basis.


The Empire Strikes Back

However, towards mid-spring, the team realized that most of the milestones were not being completed, and at each status meeting, we had action items to clean up tasks on Sharepoint. One particular week, it appeared that only 20% of the architecture refinement milestone was done, but in reality it was 80% done. This was an issue given that the team's planning, forward progress, and overall team morale depended on the tracking data from Sharepoint.

Return of the Jedi

At that time, we changed our planning process to a Scrum-like process. Team members took tasks from the backlog in a meeting, and therefore the buy-in for these tasks increased. Since the team members all took only 48 hour's(the amount of hours available in an iteration) worth of work, they also felt more responsible to finish and track those tasks. This gradually improved our tracking process, and by the end of Spring, we could rely on our tracking data.

This helped us in Summer, when we used the tracking data to measure team velocity, and planned the iterations based on that velocity. With the building blocks of tracking fixed in Spring, we were able to make enhancements such as using earned value and using trends from previous iterations burn-down.

The key takeaways from this were:

1. A good collaboration tool is essential in making tracking data available for analysis and decision making.


2. No matter how good the tracking tool is, the team has to buy into it for it to be useful to the team.