Central to MSF is the concept of the Team Model. The Team Model is a 180-degree move away from a hierarchical process structure (the waterfall approach) to embrace the concept that all team members are equal stakeholders in the software development process. This may sound simple in theory, but is actually very difficult to implement and requires cooperation and support from the very highest level of management to work.
The PMBOK discusses key stakeholders such as project managers, customers, sponsors, but - in what we regard as a huge omission from that list - neglects to discuss the rest of the team! Process methodologies were first designed with the premise that project members needed to be brought in line and controlled with an iron fist. This is really a reaction to product slips, delays, bugs, and so forth. Most process management books that you can find at a bookstore are large bricks. The emphasis is to bring a team under control and measure time very closely. However, the developer isn't always to blame for project slippages! Often, the chief cause of delays is a lack of visibility and understanding of the velocity of your team (which leads to bad estimation). Figure 13-1 shows the process flow of most waterfall projects.
As you can see, there is no feedback loop. The management and sales personnel have no idea how long a feature takes to develop. Yet, they frame the work in an artificial timeframe and expect the developers to deliver. Figure 13-2 shows the Team Model.
The Team Model is characterized by and builds trust, whereas trust is not a feature of the waterfall process. Another characteristic of the Team Model is that there is feedback between all team members at all stages of development.
A big theme in the Team Model is the concept of advocacy. If you care about and have a stake in the product, you will want to work as hard as possible to deliver it. In a waterfall approach, the developer is focused on time-to-task and meeting the deadline at any cost (even allowing bugs or sloppy code).
In the Team Model, each role within the team is an advocate for the part of the process for which they are responsible. For example, the business analyst is responsible and advocates for the needs of the customer. The developer advocates for the needs of the application. In a true Team Model configuration, a developer has equal say in what decisions are made for the application, even over management because in a trusting respectful environment, the developer really wants what's best for the product. Just because you are a project manager doesn't mean you stop making mistakes. If you are used to a waterfall like approach, the everyone-is-equal approach may seem unpalatable and radical. However, the model was not conceived in a vacuum. There is repeated precedent showing companies that are extremely successful using this management structure.
The Team Model stands for advocacy and equal representation but also communication. It's difficult for a single person (or a small group of people) to capture the big picture, every single risk, technical challenge, and so forth. One of the reasons it works so well is that it eliminates situations such as when the businessperson, who may not understand the architectural needs of the application, may, without consulting the developers, promise something that is not architecturally sound. In a Team Model environment, we gain consensus and every member of the team buys in to the project. If you feel that you are a part of the process and your opinion is respected and heard, you will more likely work harder on a project than if you feel detached and as if you are a mere cog in a big wheel beyond your control. The basis for this is psychological, but doesn't it make sense? Isn't software ultimately designed by human beings?
In the Team Model, the customer is also deeply involved in the process. This is very characteristic of agile methodologies. In Extreme Programming (XP), a close relationship with the customer is key. Why focus on the minutiae of project management artifacts and timeframes when what really counts is what the customer wants. In a Scrum methodology, the customer has a say in what features get developed within a sprint. The requirements (product backlog) are carefully managed along with the expectations of the customer.
One of the big causal factors for project failure is unrealistic expectation on behalf of the customer. The customer or sales person in a waterfall arrangement wants a product as fast as you can produce it, and expects that it magically will appear. There is a lack of visibility in the process - therefore, you can't really blame them. If a project slips, you get questions such as "Why didn't you tell me that it would take longer?" The customer is mainly concerned with the application of your piece of software from a business standpoint.
If you can't accurately predict how long a project will take, then you can guarantee that the customer also has no idea how long it will take. It is your responsibility to get a handle on your process and manage the expectations of the customer.
The term customer is used loosely here. A customer may be the CEO of your company, a business analyst, or even your development lead.