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
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
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
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
The vision should be
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
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,
Although each role has an equal value on the team, the team of peers exists between roles and should not be
The product mindset is not about whether the organization ships commercial software products or develops applications for internal customers. It's about
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
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
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
pushedresponsibility to the proper level.
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
For project success to be more than just luck, a work environment must encourage teams to make a
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
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
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
For a team to be successful, it must interact, communicate, and coordinate with external groups,
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
These traits can
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: