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.
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:
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."
We view teams as progressing through the following stages:
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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
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.
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: