No two complex organizations are alike and therefore require unique treatment, that depends on the organizational context. This makes it impossible to apply a predefined exact solution to the problem (see Cookie-Cutter anti-pattern). Practices, in order to evolve into Organizational Habits, require adjustment and tailoring (see also Best Practice Fallacy).
At the same time, there is a significant number of existing practice patterns that emerged in the industry over decades. While hardly any one of them can be applied “as is”, they provide a good idea of what could be achieved.
Following are some commonly known examples:
- Continuous Integration
- Agile Planning
- Agile Estimation
- Inspect and Adapt
- Continuous Delivery
- Mob Programming
And so on and so forth…
To be effectively used by an organization, a practice pattern has to have some of its key components:
- Practice goal
- Embedded Mental Model
- High-level mechanics
- Dependencies on other practices
The following is a significantly abbreviated example of a practice pattern for Agile Estimation:
Practice Goal: Obtaining rough approximation of the effort, risk and complexity involved in the implementation of an initiative
Embedded Mental Model: As a leader, I understand that estimation only reduces uncertainty to some level, but never actually eliminates it entirely. Teams cannot be held accountable to variation of estimates. Estimations are not a valid basis to scope commitment.
High-Level Mechanics: Estimation is performed by the people who do the work. Estimation happens in a collaborative manner with minimized peer impact. Estimates can be and often are questioned in the process, to improve understanding.
Dependencies on other practices: Cross-functional team, Gemba, Feedback Loops, Inspect and Adapt.
To facilitate actual implementation, based on a practice pattern, Thinking Tools are required. So, for example, a Relax Constraint tool can be used to adjust Cadence to specific use by enterprise teams.