Including daily builds and an updated source control system in your software development process is something of a no-brainer. As I discussed in "Daily Builds and Scrum" (http://www.sqlmag.com/Article/ArticleID/50359/sql_server_50359.html), you can use Microsoft Team Foundation System (TFS) and its Team Foundation Build (aka Team Build) add-on to automate daily builds and updates. You can do even more to improve your software development process by leveraging other TFS features in that process.
For example, you can leverage the built-in process-documentation features when you create a new TFS project. TFS ships with two processes: CMMI (Capability Maturity Model Integration) and Agile, both of which are Microsoft Solution Framework (MSF) methodologies. When you create a new project, TFS lets you select one of these processes, then populates your project's Windows SharePoint Services site with documentation and in some cases tools related to the selected process. Based on my experience, the CMMI process is typically for large, long-term projects that often need to be repeatable. The Agile process is usually for shorter projects or for the initial prototype in a larger project. When you implement TFS for the first time, you'll probably want to start with a relatively short project so that you can experiment with TFS's features.
As I explained in "Daily Builds and Scrum," Scrum is a type of Agile process that centers on breaking a project into smaller steps. For example, I was recently involved in a month-long Scrum project. As with most projects, the customer wanted an update part way through the project, so I broke the project into two sections or "sprints" in Scrum speak. Each sprint represents a set of features that will be delivered in anywhere from about 2 to 4 weeks. This time range is along enough to allow real progress but keeps a longer project from quietly wandering out of control.
As part of the Scrum process, there are two areas you need to address. The first is the feature list. The feature list gets broken into two parts. The first part is a set of features that the development team thinks it can accomplish during the course of the sprint. The second part is a feature backlog, which represents all the other features that need to be completed for the final project. Although a project might have two initial sprints, it's possible that the backlog might contain enough features for three, four, or even a dozen sprints, each of which might be a month in length. Thus, the first area of Scrum addresses the size of your project.
You can align your feature list with your project's task list in SharePoint. This TFS-managed task list gives you a tool to manage the project features. In addition, because the task list is integrated with the source control system, you'll have a way to associate code changes that are checked into the source control system with the features that each code change implements. Note that in the Agile process, the Microsoft Excel-based task list is automatically generated and populated with some sample tasks.
The second area that you need to address when applying Scrum relates to project meetings. The Scrum process does an excellent job of describing the number and length of project meetings. In short, each development cycle starts with a meeting between the development team and the customer to discuss the features to be completed in that sprint. However, during the sprint, the customer is asked to essentially leave the development team alone.
The development team meets daily throughout the sprint. The first reaction to daily meetings is typically negative, but the reality is that Scrum limits that daily meeting to about 15 minutes.
The daily Scrum meeting is less like a traditional corporate meeting and more like the morning quarters I became familiar with while in the US Navy. The point of morning quarters was to bring together a team of individuals who worked in a common area (e.g., sonar) in order to quickly dole out tasks. It wasn't a status meeting, and it wasn't a time to discuss problems that a team member might be having with an assignment. It was a quick morning meeting in which everyone checked in to get that day's assignments.
The Scrum team is much more egalitarian than the typical military team, but to a large extent, that's how the daily Scrum meetings work. The idea is to have team members commit to what they're going to accomplish each day. That way, the team can monitor its progress toward the sprint goal. Although some tasks might take longer than expected, when a task starts to run late, it's immediately evident.
When the sprint reaches its conclusion in 2 to 4 weeks, the customer and the team meet. Together, they review where the product is and start planning for the next sprint or for the deployment of the current code base.
My quick rundown of how Scrum works is a bit of an oversimplification. I want to make it clear that using Scrum doesn't mean you're suddenly going to be on schedule with every project. What Scrum does is show delays earlier in the process. Scrum helps developers focus on short-term goals and lets them work in an environment that facilitates success.
What about CMMI? As I noted previously, CMMI tends to focus on large, long-term projects. In a CMMI project, the focus is on phases. Each phase might last several months, and there isn't much in the way of short-term monitoring.
Here's an interesting comparison between CMMI and Scrum projects concerning schedule slips (e.g., you were supposed to ship a product in Q4-06 but will now ship it in Q1-07). Let's say that during the first 30-day sprint of a Scrum project, a team finds it needs a short slip, say 10 percent (i.e., 3 days). Given that the slip is only 3 days, the team might be willing to move the project's delivery date to accommodate this slip. The team can then consider this slip when it plans future sprints and reviews the overall schedule. In a yearlong CMMI project, the same 10 percent slip would be 30 days. Even worse, the fact that this yearlong project isn't on schedule won't show up (at least not to the extent that someone will admit it) for at least 6 to 8 months. And the delay will probably be admitted to only a week at a time. For example, team members might initially tell the customer that the project is running about a week late, then a few weeks or even a few months later, they'll ask for another extension, then another, then another. Such extensions will erode customer confidence. By the way, internal customers are still customers and can still lose faith in their internal software organization.
I've been on many large projects that have suffered this fate. A methodology that forces you to deliver every month helps avoid this fate because you can see a trend develop and see its impact on the overall schedule. If every sprint was planned at the start of a project (which is common) and suddenly 50 percent of the originally assigned work isn't being done every sprint, the impact to the overall schedule becomes obvious, even 2 or 3 months into the project. At that point, the project's priorities can be reviewed.
Even though product managers are sometimes resistant to implementing an iterative methodology, they can still apply Scrum's basic rules to CMMI projects in order to better monitor progress and track short-term deliverables. The Agile-process tools that TFS provides for matching task lists to code check-ins are available to the CMMI process.
For more information about the MSF methodologies I've discussed here, I
check out these two links:
