Building Successful Teams

The MSF Development Team Model provides a team structure for tackling enterprise application projects, but the quality of the people that make up the team is a huge factor in the project's success. In this section, we examine some of the ways to ensure that quality.

Finding Effective Leaders

For the person in charge of putting together a project team, the first task is to decide who will work on the project. This seemingly simple (but more often complex) decision can dramatically affect the project's outcome.

Finding leaders within an organization is not a difficult process. By definition, leaders are recognized by those they work with. It's important to remember that we are talking about leaders here, not bosses. Every organization has its share of managers, directors, and so on, but the hierarchical structure of an organization does not determine who the true leaders are. Actions and characteristics, rather than job titles, identify leaders.

Why do we need leaders? Because we have so many followers. It's important to realize that labeling people as leaders and followers does not imply a value judgment. We must have leaders to be successful, but we must also have followers. Leaders provide direction for the team. Followers get the work done. The team needs to strike a balance between its leaders and followers. It must decide what to do and then must do it, so both leaders and followers are equally important and valuable. An absence of either leaders or followers will hinder the project's success.

Certain characteristics are present in many leaders. Common qualities of leaders include:

• Understanding and meeting the needs of others.
• Communicating well with groups and individuals.
• Earning the respect of internal and external customers.
• Displaying commitment to well-defined purposes.
• Making a positive difference.
• Having confidence in his or her abilities.
• Practicing good problem-solving skills.
• Helping others to develop their skills.

Many people will read this list and say, "I do those things." More people will read this list and say, "I intend to do those things." But being a leader also means knowing the difference between intent and impact. When measuring their own success, people measure their intent; when measuring other people's success, they measure their impact. The impact that leaders have on others may or may not be their intent, and leaders' intent may not have the impact they were striving for. The proper way to measure people's leadership skills is by the impact they actually have, not by their intent. We can summarize this concept by saying, "Other people's perceptions are reality."

Improving Team Effectiveness

We view teams as progressing through the following stages:

• Awareness/concern
• Hope/optimism, willingness
• Identification of needs and solutions
• Supportive/caring behaviors
• Trusting/respectful relationships
• Team cohesiveness

The goal is to have all teams move to the last stage, team cohesiveness, where productivity is the highest.

To be successful, a team has to do more than just define roles and responsibilities. Along with the team structure, there must also be some underlying practices and principles that help to ensure the success of the team. Following is a discussion of "best practices and principles" that have helped to make the MSF Development Team Model a success internally at Microsoft and with customers and partners who have implemented MSF.

Shared Project Vision

Fundamental to the success of any project is getting team members and the customer to share a project vision—that is, a clear understanding of the project's goals and objectives. Team members and the customer all bring with them assumptions and hidden agendas regarding what the project and the product are going to do for the organization. The process of establishing a shared vision brings those assumptions and agendas to light and ensures that all project participants are working to accomplish the same goal.

The vision should be formalized as a Vision Statement that is the basis for the first project deliverable. An effective Vision Statement:

• Describes not only what the product is, but also what it is not.
• Provides guidance for defining the product (for example, features are included or omitted to suit the vision).
• Motivates the team to achieve the vision.
• Is achievable so that both the team and customer can commit to it.

NOTE

---

Writing a Vision Statement doesn't guarantee that the project team, customer, and users will all share it. The vision must be effectively communicated so that everyone understands it.

Without a shared vision, project participants will invariably have competing drives, making it much more difficult to reach the project's goals as a cohesive group. The most effective tool for communicating the vision is to talk about what the goals are and why the project has been undertaken. This discussion provides an opportunity to gain real commitment from the project participants. Commitment is not simply an agreement: "Yes, we'll work on the project." Commitment is motivation: "Let's get going. We can make a difference." The Product Management or Program Management teams will often need marketing experience to get project participants truly committed to the project early in the development process.

CAUTION

---

Never assume that others understand what the project team is doing or why it is doing it. The team and the customer should discuss the project's vision thoroughly.

Team of Peers

In a team of peers, each role has equal value. This peer approach enables unrestricted communication between the roles, increases team accountability, and reinforces the concept that all six goals are equally important and all must be achieved. For a team of peers to be successful, all roles must have ownership of the product's quality, must act as customer advocates, and must understand what business problem they are trying to solve.

Although each role has an equal value on the team, the team of peers exists between roles and should not be confused with consensus-driven decision-making. Each role requires some form of hierarchy for the purposes of distributing work and managing resources. The leaders of each role are responsible for managing, guiding, and coordinating the role's effort, while the other members of each role focus on meeting their individual goals.

Product Mindset

The product mindset is not about whether the organization ships commercial software products or develops applications for internal customers. It's about treating the results of people's labor as a product.

The first step to achieving a product mindset is to look at the work being done either as its own project or as contributing to a larger project. MSF advocates the creation of project identities so that people see themselves less as individuals and more as members of a project team. One effective technique Microsoft uses to accomplish this step is to give projects code names (such as "Chicago" for Windows 95 and "Memphis" for Windows 98). The code name helps to clearly identify the project, clearly identify the team, raise the sense of accountability, and serve as a mechanism for increasing team morale. Printing the team's project code name on T-shirts, coffee mugs, and other group gift items are ways to create and reinforce team identity and spirit.

Having a product mindset means being more focused on execution and what is being delivered at the end of the project, and less focused on the process of getting there. That doesn't mean that the process is bad or unimportant, just that it should be used to accomplish the end goal and not for its own sake. A strict adherence to process should never get in the way of delivering a product. With the adoption of the product mindset, everyone on the team should feel responsible for product delivery.

Former Microsoft program manager Chris Peters describes the product mindset as applied to software development in the following excerpt from a 1991 presentation:

Everybody … has exactly the same job. They have exactly the same job description. And that is to ship products. Your job is not to write code. Your job is not to test. Your job is not to write specs. Your job is to ship products. That's what a product development group does.

Your role as a developer or as a tester is secondary. I'm not saying it's unimportant—it's clearly not unimportant—but it's secondary to your real job, which is to ship a product.

When you wake up in the morning and you come in to work, you say, 'What is the focus—are we trying to ship or are we trying to write code?' The answer is, we are trying to ship. You're not trying to write code, you're trying not to write code.

Zero-Defect Mindset

The zero-defect mindset is a commitment to quality. It doesn't mean delivering a product with no defects; it means that the product meets or exceeds the quality bar that was set by the team's project vision. Additionally, it means that the goal of the team is to work at the highest quality level possible all the time, so that if a working product has to be delivered tomorrow, the team has one to deliver. It's the idea of having a nearly shippable product every day.

In a successful team, every member feels responsible for the quality of the product. Responsibility for quality cannot be delegated from one team member to another. In this sense, every team member is a customer advocate.

Understanding the Business

To be successful, it's not enough for a team to be technically competent in the ways of software development. Many a great product did not meet the business objectives of the customer and, although well written and technically sound, was shelved. To avoid this pitfall, the team members need a clear understanding of the business problem that they are trying to solve.

One way to achieve this understanding is to have active customer participation and feedback throughout the development process. This includes customer participation in establishing the product vision, signing-off on what is going to be built, taking part in tradeoff decisions, and adding feedback through usability studies and beta releases.

Overlapping Roles and Shared Responsibilities

As Chris Peters humorously put it in a 1991 presentation:

It's extremely important to move responsibility very low in the organization. Your goal is not to be working on a project where you can't sleep at night. Your goal isn't to have it so that the project leads can't sleep at night. Your goal is so that nobody sleeps at night. And when nobody is sleeping at night, you have pushed responsibility to the proper level.

To encourage team members to work closely with each other, they should be given broad, interdependent, and overlapping roles, and they should all share responsibility for shipping the right product at the right time. This approach discourages specialization among team members, which often leads to isolated, rather than collaborative, effort.

Total Participation in Design

Jim McCarthy summarizes the concept of total participation in design in Dynamics of Software Development:

The goal in any product design is to have the best ideas become the basis of the product. Everybody on the team should be working to accomplish that goal.

Each role participates in the generation of the Functional Specification because each role has a unique perspective of the design and tries to ensure that the design meets their role's objectives, as well as the project team's objectives.

Learning from Current and Past Projects

For project success to be more than just luck, a work environment must encourage teams to make a deliberate effort to learn from current and past project successes and failures. Creating a learning organization is fundamental to ongoing improvement and the continued success of projects. One method for structuring this type of behavior is post-milestone reviews, or postmortems. After the team reaches a milestone, it reviews the lessons it learned. This review allows the team to make midcourse corrections to avoid repeating mistakes, and to highlight what went well so that best practices can be created and followed.

NOTE

---

It is very important that best practices be shared both within and across teams throughout the organization.

Summarizing the principles of project staffing in Barry Boehm's Software Engineering Economics (Prentice Hall, 1981), we offer these guidelines:

• Top talent Use better and fewer people.
• Job matching Fit the tasks to the skills and motivation of the people available.
• Career progression Help people self-actualize.
• Team balance Select people who will complement and harmonize with one another.
• Phase out Cull misfits.

Educating the Team

For a team to be effective, it must understand what it's doing. Many organizations pay only lip service to this simple guideline. Having both a formal and an informal training plan for the project team will smooth the process of shipping the right product at the right time.

Process Education

The process of developing software, as we refer to it throughout this book, is much more than the process of writing code. Formal education about the development process for the team leaders, major stakeholders, and significant project contributors will decrease the overall cost and time schedule for most projects.

Improving communication should be a goal for every project. Training in MSF or other development processes provides the common language for communicating responsibilities and project status. The ideas behind the process have existed for years, and most developers have used some or all of these practices in many of their development projects. Using the common language of MSF, experienced developers can effectively teach others what they know, and team members can relate their own experiences within an easily understood framework.

Technical Education

Creating great products is a difficult task. Technical training must be provided for the Development team, the Logistics Management team, and possibly the Program Management team. New forms of training are created on a daily basis to explain new technologies, but the key to implementing those new technologies is not just to learn about their features, but also to understand best practices.

As an example of the range of technical skills and knowledge that might be required for a project, the following is the skill set needed for working with all aspects of the application code for the Resource Management System (RMS) described in the case studies that are scattered throughout this book:

• HTML
• Dynamic HTML
• Microsoft Active Server Pages (ASP)
• Microsoft Visual Basic Scripting Edition (VBScript)
• Microsoft Internet Information Server (IIS)
• Microsoft Windows NT 4.0
• Microsoft Windows 2000
• Microsoft Systems Management Server 2.x (SMS)
• Microsoft Outlook 2000 programming
• Microsoft Visual InterDev
• Microsoft Visual Basic 6.0 (VB)
• Microsoft Visual C++ 6.x (C++), ATL, STL libraries
• Microsoft Transaction Server 2.0 (MTS)
• Microsoft SQL Server 7.x
• Creating COM objects using VB and C++
• Using the ActiveX Data Objects (ADO)
• Using the Collaborative Data Objects (CDO)

Often forgotten on the training front is a method for understanding the support of the application in the organization's current environment. Successful projects aren't just about getting the code written. The project team needs to consider how the product will affect and be affected by the rest of the environment. What will be the future impact on the product of introducing a new operating system, a new version of the existing operating system, or new base applications used by the product?

The team should also expect software vendors to release new technology products and product revisions during the project, and should be able to determine the impact of new features and support issues with new product revisions during the project's lifecycle. The team should include training sessions in the overall project schedule before committing to any ship dates.

Coordinating with Outside Teams

For a team to be successful, it must interact, communicate, and coordinate with external groups, ranging from the customer and users to other product development teams. Program Management, Product Management, User Education, and Logistics Management are the primary coordination facilitators. These roles are both internally and externally focused, whereas Development and Testing are internally focused and insulated from external communications. (Insulating the Development and Testing teams from external interruptions provides more efficient project delivery.)

It is important that the interfaces with any external groups be explicit and well understood. Figure 3.3 illustrates how coordination occurs with either a business focus or a technology focus. The diagram represents a high-level perspective. Teams typically have to coordinate with many more external groups, such as quality assurance, finance, and legal.

Figure 3.3 Internal and external team communications

Team Management Tools

To effectively manage a strong team, team leaders must possess a range of skills and characteristics that promote communication and teamwork. Continually building and monitoring these skills can help leaders establish a set of best practices for their organization. Below is a list of simple statements that identify several key leadership characteristics and constitute a Leadership Evaluation Checklist as created and distributed by Microsoft Consulting Services. As we discussed at the beginning of this chapter, how a person responds to these statements about himself or herself represents the person's intent; how others respond to the statements about that person represents his or her actual impact.

• I have a long-range view of things.
• I promote innovation and new ideas, and I engage stakeholders in the planning/creative process.
• I encourage people to consider how things could be better, and I enjoy communicating the possibility of a better future.
• I have a clear understanding of how the overall organization works and where it is going.
• I think about "what and why" more than "how and when."
• I have a firm sense of purpose and commitment, and I act on my commitments.
• I am action-oriented, and I can mobilize people and resources.
• I cultivate mutual respect and trust, and I share decision making where appropriate.
• I tell the truth, and my values and beliefs are clear to others.
• I let people know when they've done a good job.
• I let people know I care about what they are doing, and I work to bring out the best in people.
• I promote teamwork, and I foster team goals and commitment.
• I keep channels of communication open, and I communicate plans and goals to the stakeholders.
• I continually evaluate progress against plans.
• I deal with problems in proportion to their importance.
• I make sure people understand their responsibilities, I hold them accountable, and I provide honest and timely feedback.

These traits can turn a team from a loose group of individuals into a team capable of achieving goals much greater than any individual alone can accomplish. It is important to remember that these traits, along with education in the development process and training in technical issues, must be considered integral tools for effective teams.

Often, both customers and product developers see themselves as misunderstood by the other. As a quick reminder of the important relationship between these two groups, project teams can use the Customer's Bill of Rights and the Developer's Bill of Rights provided below to guide their interactions and communications:

• Customer's Bill of Rights The Product Management team might want to bear in mind the following customer's rights, taken from Steve McConnell's Software Project Survival Skills:

• To set objectives for the project and have them followed
• To know how long the project will take and how much it will cost
• To decide which features are in and which are out of the product
• To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
• To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
• To have ready access to project deliverables throughout the project

• Developer's Bill of Rights Steve McConnell provides a similar bill of rights for the Development team in Software Project Survival Skills:

• To know the project objectives and to clarify priorities
• To know in detail what product is to be built and to clarify the product definition if it is unclear
• To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality
• To work each phase of the project in a technically responsible way, and especially to not have to start coding too early in the project
• To approve effort and schedule estimates for any requested work, including the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change
• To have the project's status reported accurately to the customer and upper management
• To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project