Principles vs. practice

DecisionOps emphasizes doing vs. knowing

I want to argue that tools/rituals and practice trumps intent/principles of effectiveness in the workplace and life in general. "What you do" is more potent than "what you think" or "what you intend." 

Consider the successful industry-wide adoption of agile practices for software development. The agile manifesto (https://agilemanifesto.org/) famously values individuals and interactions over processes and tools. I want to argue that agile practices' success has been due to the adoption of standards, methods, and tools that embody the principles rather than its intent and principles alone. Agile practices would be less prevalent if not for the availability and adoption of tools like JIRA, Asana, etc.

Another instance of this is the success of "getting things done" (https://gettingthingsdone.com/). Effective time management and discipline have been fodder for decades of self-help books. No one would disagree with the spirit and intent expressed in these books. However, "Getting things done" provided rituals/tools that one can use to implement the principles. I would argue that the set tools and practices of GTD are what made it successful. 

Consistent execution ("practice") of principles is crucial to achieving effective outcomes. Therefore, decisionOps emphasize practice (operations) over disembodied strategy. For each principle, you'd like the team to adopt and internalize, consider tools and rituals that assist in that adoption. 

As an example, let us consider two tools that increase the effectiveness of individuals and teams.

OKRs: OKRs (https://en.wikipedia.org/wiki/OKR) is a set of tools to set and monitor goals. Initially introduced by Andy Grove at Intel, Google's company-wide adoption made it famous. OKRs define objectives/challenges and measurable key results (milestones to achieve goals). OKRs are set quarterly, providing enough time for meaningful execution and frequent enough to react to changing organizational objectives. OKRs can be set hierarchically, with OKRS defined at the company, department, team, and individual levels, providing a guide for execution at all levels. For example, OKRs can inform how a product backlog is structured and, for individual contributors, provides a framework of what to do next. 

Office hours: Office hours are predictable time commitments from team members to address pressing questions. Office hours serve two purposes: they time-box ad-hoc interruptions and make interruptions predictable. Office hours are especially needed if your team regularly interacts with customer success, sales engineering, or other partner teams. Partner teams understand that they have a predictable/frequent venue to discuss their concerns and avoids "urgent" issues and escalations.

What are some rituals/tools/processes that you use within your teams? What are the underlying intents and principles behind those rituals? Please contribute your comments and suggestions.