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 decides how to act and is faced with a complex decision, principles provide a guiding set of constraints - a framework - within which a decision on the correct course of an action is more easily made. Mindsets and principles of our organization 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.

Easy to work with

If we had to summarize our thinking in only one phrase, it would be this one. Being "easy to work with" means that you are always trying to make the work of your team members easier by providing them with detailed information of your activities and findings. Helping them better understand how to best interact with you, what you understood out of the things you are doing.

Quality Is Defined By Customer

Satisfied customers are priority number one for our team. Customers in this case are the end-consumer of a 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 from which they derive value. Like in MSF, to us 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 highest degree possible to ensure that their expectations are aligned with the product features committed 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 providing high quality in terms of functioning without errors.

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 heartfelt 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 is thus lost. We ask for every team member 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. Although different roles have different focus within different tracks, all constituencies are equally important for risk modeling of the project management and successful delivery of a quality product. A team of peers calls for team accountability and shared responsibility in order to achieve effectiveness and success.

Frequent Delivery

Early and frequent delivery builds trust amongst the team and externally with sponsors, business owners, and product consumers. 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, while 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 of making 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. By keeping a small batch the number of issues and risks to monitor and resolve will remain small. Quality is higher with small batches because each single 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 early detected. 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 unique 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 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 knowledge. 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 their 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 debate abstract vaporware. Techniques supporting this mindset include personas, scenarios, design for deployment, and test cases.

Qualities of Service

Qualities of service take the solution into account and develop plans based on every aspect of customer’s experience. 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, our process turns implicit assumptions into explicit requirements of quality. Techniques supporting this mindset include using specialist expertise where you need it and discovering risks as early as possible.

Citizenship

Behave yourself as a good 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 share knowledge and recognize that the whole takes precedence over the individual. Citizens act for the greater good. Citizens think end-to-end about the system of software engineering. Citizens value every contribution towards the achievement of the product vision and delivery of successful projects.