I found the conclusion to be my favorite part:<p>Skepticism is a valuable counter to an unreasonably rosy picture of the world that only looks at the best cases for outcomes. While a positive attitude is essential, it’s often best to "hope for the best and plan for the worst."<p>In practical terms, applying skepticism often means making space for team members to question assumptions and assertions by looking for ways to prove (or disprove) the team’s assumptions. Skepticism means more than simply cataloging assumptions; it means actively investigating whether those assumptions are valid.<p>Teams need to recognize that every requirement, including Quality Attribute Requirements (QARs) that drive the architectural design, represents a hypothesis about value. One of our goals when taking a skeptical approach is to make these hypotheses explicit and to consciously design experiments that specifically test the value of the requirements.<p>Being skeptical is not a sign of disrespect; it’s actually a sign of sincere respect for the complexity of delivering excellent outcomes to customers in a chaotic world. It means taking seriously the team’s commitment to seek desirable outcomes expressed in product goals and QARs. Skepticism helps teams to question assumptions and hidden biases in a positive way.<p>Thoughtfully employing skepticism can be essential to every software development team’s tool kit. It can help them make better decisions earlier in the development cycle and at a much lower cost.