The Need for a Methodology

The Need for a Methodology

Let's back up for a moment. I believe, and most would agree, that having a methodology is important, no matter what kind of methodology it is. If your methodology is to write down all the tasks you're going to do for the day onto sticky notes, prioritize them, stick them to your wall, and then remove them when you've completed them, you have a methodology. Even the term “methodology” is not very concrete. It simply means that you have a concise and consistent approach to accomplishing something. There are well-known methodologies as well as obscure ones. This area has fascinated me for many years because it represents an intersection of soft organizational skills with hard technical ones.

NOTE
Team System itself is not a methodology. It is simply a tool that provides guidance and communicates which items need to be worked on. It does so according to whatever methodology you happen to be using. That said, I love the irony in Team System: Some teams need a tool to get them to use a methodology to guide them to use the tool.

The next few pages will highlight some of the more popular methodologies, including the two Microsoft Solutions Framework (MSF) methodologies that will be included with Team System.

More Info
Be sure to read Chapter 8 for a deeper look at the MSF methodologies.

Microsoft Solutions Framework

Microsoft Solutions Framework (MSF) is a set of software development processes, principles, and proven practices that enable developers to achieve success in the software development life cycle (SDLC). MSF is rooted in well-known industry best practices. First introduced in 1994, MSF has aggregated 25 years of guidance from both internal and external sources.

Over the years, MSF has morphed to meet the changing needs of developers. MSF version 4.0, which ships with Team System, breaks down into two versions, which are essentially two philosophies on how to develop software: MSF for Agile Software Development and MSF for CMMI Process Improvement. MSF for Agile Software Development will appeal to the “agilists” out there—that is, teams accustomed to more rapid, ready-for-change environments that are tightly coupled with the customer. MSF for CMMI Process Improvement will appeal to larger shops or larger projects that feature many reporting levels. These are typically projects in which long-range planning and communication are more important than constant deliverables and feedback.

MSF for Agile Software Development

The MSF for Agile Software Development process is brand new. It is intended for smaller shops, with 5 to 20 members on the development team. Was MSF for Agile Software Development created specifically for Team System? Probably. Was Team System created to complement MSF for Agile Software Development? Probably. The integration of the process and the tool is very natural.

Officially, the agile process model was created by a council known as the Agile Alliance. Here are some tenets that the Agile Alliance agrees on:

• Individuals and interactions are more important than processes and tools.

• Customer collaboration is more important than contracts.

• Working software is more important than comprehensive documentation.

• Responding to change is more important than following a plan.

Delivering consistent and quality software defines an agile process. Gone are the days of formal specification phases. With MSF for Agile Software Development, Microsoft demonstrates its recognition that throwing hard-and-fast specifications and requirements over the wall to the developers often results in failed projects.

MSF for Agile Software Development is the default methodology in Team System. You can really feel that tight coupling when you use it. The default artifacts, which include tasks and bugs, are intuitive to developers who have used Visual Studio.

MSF for CMMI Process Improvement

CMMI stands for Capability Maturity Model Integration. Its purpose is to provide a model for continuous process improvement. This results in reduced software development–cycle times, improved ability to meet cost and schedule targets, and improved quality. It is a formal methodology managed by the Software Engineering Institute of Carnegie Mellon University.

One of the major advantages of using CMMI is that it is an evaluated standard by which you can compare your ability to develop software against other firms. Specifically, the U.S. Department of Defense and other large software consumers often look at the CMMI rating achieved by their vendors in order to determine who should receive a development contract.

Team System implements CMMI for Process Improvement that is specific to software engineering. This is an excellent process to use on your project if your company is attempting to achieve a measured baseline competency in software development. Far more status documents and reports must be completed in this model than in MSF Agile, but this more formal development process reduces risk on large software projects and provides a baseline that can be used to achieve certifications in the various CMMI levels or ISO 9000/9001.

eXtreme Programming (XP)

eXtreme Programming is another agile SDLC methodology that enables the team (developers, customer(s), and project lead) to handle changes throughout the development of a project. As you know, requirements can change frequently during a project. For that matter, in XP, just about everything can change—including the members of the customer and development team, along with the business environment. Waterfall and other fixed SDLCs cannot easily handle changes, especially later in their respective cycles. XP is an SDLC that not only handles changes but also deals with them elegantly. Instead of trying to control a change, the XP practices enable team members to adjust to that change easily.

TIP
“Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn't change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes.”

—Kent Beck, eXtreme Programming Explained

There are many advantages to XP:

• Customers get the first product on which they can start working within one customer iteration. (The first actual iteration might be for the development team to set up its environments.)

• Developers are working on the most important features, as prioritized by the customers.

• The most important functionality and features of the system get the most testing.

• The product delivered meets the needs of the customer.

NOTE
This is just an overview of XP. Full descriptions of these values and practices are available in many excellent books currently available.

Scrum

Scrum is another agile development methodology that focuses on incremental delivery using small development teams, short development cycles, and a facilitator who keeps the team focused and productive.

A Scrum project is broken up into one or more sprints, a well-defined development cycle that is typically four to six weeks in duration. After the initial project planning is complete, the deliverables for the first sprint are determined jointly by the customers and the development team. Then the team begins the sprint, focusing on it to the exclusion of all other tasks. The short duration of the sprint creates a sense of immediacy that keeps the team motivated. Sprints help the team keep the end in sight because the end is, at most, a few short weeks away. Each sprint finishes with a retrospective, where the team reviews how the sprint went and explores ideas for improving the next sprint. The end of one sprint signals the beginning of the next sprint. This cycle continues until the project is complete.

At the center of the team is the scrum master, a facilitator whose primary and often only responsibility is to guide the team through a successful sprint. The scrum master conducts a daily scrum, which is a short meeting of the entire development team. The agenda for the daily scrum consists of three simple questions for each team member:

• What have you accomplished since the last scrum?

• What do you plan to accomplish by the next scrum?

• What is impeding your progress?

Any other discussions that come up during the scrum are deferred to follow-up meetings with the appropriate people. This keeps the scrum meeting short and productive for all who attend.

The scrum master is responsible for removing the impediments identified in the scrum meetings. This function, which is often missing in development teams, is a key component of the scrum process. Impediments ranging from equipment issues to pending decisions to missing upstream deliverables can have a major impact on a development team. Giving one person responsibility for these distractions clears the way for the developers to focus on the task at hand.

By applying these simple techniques, a software development team can achieve significant improvements in productivity and morale.

NOTE
This methodology gets its name from the sport of rugby. Scrum is short for scrummage, which evolved into the term scrimmage used in American football.

How Team System Supports These Methodologies

No matter how lofty and theoretical your methodology is, you still need to bring it down to earth, implement it, and get your work done. This is where Team System comes in. Team System takes a work-stream approach, which means that it defines a process by offering a collection of activities and subactivities. This model fits well with most methodologies.

For example, Team System knows about the MSF for Agile Software Development elements: roles, work items, activities, and work streams. Roles are identified as business analyst, project manager, architect, developer, tester, and release manager. Work items are the various scenarios, quality of service requirements, risks, tasks, or bugs. These work items might link to artifacts, such as documents, spreadsheets, project plans, source code, and other tangible output from activities. Work items are created when certain activities are completed. They can also be prerequisites to perform an activity. Activities are a pattern of work performed together for a single purpose. An activity can use or produce work products and can be tracked by a work item. Activities are grouped together into work streams. Work streams are activities composed of other activities. They are the simple building blocks of the process and can be assigned to single or multiple roles.

Scenario

A scenario is a type of work item, recording a single path of user interaction through the system. As the person attempts to reach a goal, the scenario records the specific steps that he or she will take. Some scenarios will record a successful path; others will record an unsuccessful one. When writing scenarios, be specific. Because there are an infinite number of possible scenarios for all but the most trivial systems, it is important to be discerning in deciding which scenarios to write.

NOTE
A scenario is often compared to use case in Unified Modeling Language (UML).

Quality of Service Requirement

Quality of Service (QoS) Requirements document characteristics of the system, such as performance, load, availability, stress, accessibility, serviceability, and maintainability. These requirements usually take the form of constraints on how the system should operate.

NOTE
Quality of Service Requirements are not the same as functional requirements.

Task

A task work item communicates the need to do some work. Each role has its own requirements for a task. For example, a developer uses development tasks to assign to component owners work that has been derived from scenarios or quality of service requirements. The tester uses test tasks to assign the job of writing and running test cases. A task can also be used to signal regressions or to suggest that exploratory testing be performed. Finally, a task can be used generically to assign work within the project. On the work item form, certain fields are used only in cases when a task relates to a particular role.

Risk

An essential aspect of project management is to identify and manage the inherent risks of a project. A risk is any probable event or condition that can have a potentially negative outcome on the project in the future. A risk work item documents and tracks the technical or organizational risks of a project. When concrete action is required, these risks can translate into tasks to be performed to mitigate the risk. For example, a technical risk can set off an architectural prototyping effort. The team should always regard risk identification in a positive way to ensure contribution of as much information as possible about the risks it faces. The environment should be such that individuals identifying risks can do so without fear of retribution for honest expression of tentative or controversial views. Teams creating a positive risk management environment will be more successful at identifying and addressing risks earlier than teams operating in a negative risk environment.

Bug

A bug is a work item that communicates that a potential problem exists or has existed in the system. The goal of opening a bug is to accurately report bugs in a way that allows the reader to understand the full impact of the problem. The descriptions in the bug report should make it easy to trace through the steps used when the bug was encountered, thus allowing it to be easily reproduced. The test results should clearly show the problem. The clarity and understandability of this description often affects the probability that the bug will be fixed.

Customizing Methodologies

As I've said previously, Team System is not a complete methodology tool. For example, it only supports the core development team. It won't schedule meetings, prepare budgets, send e-mail, or facilitate communication with the customer or other stakeholders directly. In an enterprise where the customer is on-site, possibly in another division or department, this functionality might be missed. For an ISV selling software online, this functionality would not be missed.

Team System does a great job of organizing all your project work items, expectations, and collaboration tasks. Real people and real meetings, however, will still be required to implement a methodology, and this is outside the scope of Team System.