MSF for CMMI Process Improvement Visual Studio Team System logo

Mindsets


A mindset is a framework for thought (also known as a paradigm). A mindset is defined by a collection of principles. Principles are abstract concepts used to guide and constrain concrete activities. When a team member is deciding how to act and is forced with a complex decision, principles provide a guiding set of constraints - a framework - within which to decide the correct course of action. Mindsets and principles of MSF should become ingrained in the mind of every team member. They should refer to them daily as they make decisions to guide and steer the project, prioritize work, and interact with stakeholders.

Principles and Mindsets


Quality Is Defined By Customer - Satisfied customers are priority number one for any team. The customer in this case is the end consumer of the product or service. There is only one customer in the value chain; the consumer at the end of the chain. Everyone on the team should be aware of the consumers for the product and be focused on delivering something that they need, want, and will derive value from. In MSF, consumers are defined using personas. A persona focus throughout development means having a commitment from the team to understand and solve the persona’s problems. Once understood, real consumer involvement must be maximized to the degree possible to ensure that their expectations are aligned with the product features committed to for the project. Techniques that support setting and managing consumer expectations include reporting on the backlog, building small batch sizes (or highly iterative delivery), and high quality in terms of functioning without errors but more so in terms of correct interpretation of the needs and wants of the persona and the consumers that the persona represents.


Pride of Workmanship - Pride of workmanship is core to any craft or profession. Pride of workmanship is the notion that every craftsman involved in a product takes a deep heart felt care and passion in the quality of the finished product. Division of labor and 20th Century mass production thinking tended to weaken pride of workmanship. It was too common to simply throw the work to the next guy in the chain and wait for the quality control department to reject the defects. Much of this thinking crept into software engineering with the idea that specialized analysts pass work to specialized designers, who pass it to coders, who pass it to testers and so forth. Pride of workmanship in the quality of the end product was lost. MSF asks for every member of the team to take a pride in the quality of the end product and to do their best to ensure that quality assurance is embedded at every step in the life cycle.


Team of Peers - A team of peers implies that equal value is given to each constituency in the Team Model. Though different roles have different focus within different tracks, all constituencies are equally important to the risk management of the project and successful delivery of a quality product. A team of peers calls for team accountability and shared responsibility for effectiveness and project success.


Frequent Delivery - Early and frequent delivery builds trust amongst the team and externally with sponsors, business owners, and product consumers. Trust is the grease which lubricates a highly productive software engineering organization. Trust enables agility and reduces the need for verification, documentation, and checkpoints. The frequency of delivery should be tuned to the cadence of the business domain. In some domains, delivery every day makes sense, whilst in others it will be quarterly, bi-annually, or annually. There is a transaction cost to delivering a shippable product and that cost must be understood and factored against the desire to make the frequency of delivery as short as possible. Frequent delivery reduces the batch size for an iteration or release, and hence the iteration or release cycle is shorter. Small batch sizes are good for risk management but also facilitate flow of value and quality. It is easier to keep a small batch moving, the number of issues and risks to monitor and resolve will be smaller. Quality is higher with small batches because each individual function receives better focus and attention from the team. Through frequent delivery, process and infrastructure are proven and improved. Risks, bugs, and missing requirements are detected early. Feedback can be provided when it can make a difference. Some keys to frequent delivery are keeping batch sizes small, working on deliverables in a "just-in-time" manner, and keeping options open by postponing decisions to the last responsible moment. This is embodied in the late planning techniques which only lock fine-grained commitments at the start of each iteration. Frequent delivery enables quality, continuous improvement, trust, better flow, increased productivity, and overall better economic performance from the organization.


Willingness to Learn - Since each development project, environment, and team is unique, each project and iteration within the project creates a learning opportunity. However, there can be no learning without honest feedback and reflection. Unless there is a supportive, risk tolerant environment that fosters personal safety, feedback will be limited and be unable to facilitate continuous improvement. Once a framework is in place to facilitate learning, individuals and teams can focus on continuous improvement, gathering and sharing of knowledge, and root cause analysis of special cause (or chaotic) events which disrupt plans, schedules, and commitments. Proven best practices from external sources can be introduced under controlled, objective conditions and monitored for their effect. Learning opportunities include peer reviews, iteration retrospectives, operations reviews, and process and guidelines tailoring activities.


Get Specific Early - Abstract thinking is a useful tool. However, abstractions by their very nature lack definition and detail. Using abstract techniques often leads to a diversity of thought across a team. By getting specific early, and developing concrete examples using personas and scenarios, a team can better align its thinking and come to a shared vision and consensus on the work to be undertaken. Being abstract too long adds risk to a project and undermines team effectiveness. Too many projects lose time procrastinating about the "big" picture instead of tackling solvable problems. Take one small step at a time, get specific, use concrete examples, and build concrete working code. Learn from these specific concrete examples rather than debatr abstract vaporware. Techniques supporting this mindset include personas, scenarios, design for deployment, and test cases.


Qualities of Service - A quality of service mindset looks at the solution and develops plans based on every aspect of customer experience. The idea is that qualities of service such as performance and security should not be considered late in the project but throughout it. When ignored, these qualities of service are ultimately consumer dissatisfiers. The consumer is dissatisfied because the quality of service is implicitly assumed. In the spirit of getting specific early, MSF turns implicit assumptions into explicit quality of service requirements. Techniques supporting this mindset include using specialist expertise where you need it and discovering risks as early as possible.


Citizenship - Be a good project and software engineering organization citizen. Team members are encouraged to treat others as they would want to be treated and to treat project and organization assets as if they were their own. A good citizen is a steward of corporate, project, and computing resources. Citizens seek to reuse resources and to provide resources which can be reused. Citizens clean up their own mess. Citizens keep their home and its precincts tidy. Citizens share resources and do not hog valuable assets for their own use. Citizens share knowledge and recognize that the whole takes precedence over the individual. Citizens act for the greater good. Citizens think holistically about the system of software engineering. Citizens value every contribution towards the achievement of the product vision and delivery of successful projects.

(C) 2005 Microsoft Corporation. All rights reserved.

MSF for CMMI Process Improvement: Build 050707