Patterns not Practices
there are no best practices
Agile principles are sound, yet too often we end up in a forest of best practices that start as hopeful little saplings but quickly grow to become an end in themselves. It’s always good to be investing forward in building capabilities, but when the cultivation of practices begins to soak up serious resources at the expense of building and releasing software, then it might be time to fallback to a pragmatic attention to the actual circumstances of time and place.
There are good practices in context, but there are no best practices.
— Cem Kaner
Driving practice adoption in response to current constraints of the process is a safe way to go, building capability while solving immediate problems at the same time. It puts practice adoption in tow to the issues at hand; your best defense against a recidivist constraint.
In 1977, Christopher Alexander and friends published A Pattern Language, establishing a paradigm for talking about principles in the context of an advanced discipline while avoiding prescriptive formulations. Patterns are a higher-order vocabulary making metaphor more accessible in technical conversation.
From a sequence of these individual patterns, whole buildings with the character of nature will form themselves within your thoughts, as easily as sentences.
— Christopher Alexander
The use of the term “Pattern” in software design has been more along the lines of something to be copied for reuse. The intention in A Pattern Language is something more.
We know a stairway provides the utility for a person to go from one level to another, but we may also want to invoke a pattern to communicate a design purpose such as “inviting”. This particular stairway should be an invitation to ascend". This kind of subtlety will help insure that UX goals are not boiled off in the process of technical implementation.
What Constitutes a Good Pattern?
Coherence to Agile principles and universality of application are two criteria which help in distinguishing an otherwise interesting anecdote from a generally useful pattern. Patterns that serve to reinforce framework preferences are to be avoided. We strive for an organic order.
We define organic order as the kind of order that is achieved when there is a perfect balance between the needs of the parts, and the needs of the whole.
— Christopher Alexander
Viable Agile Patterns are unlikely to emerge from sheer abstraction, but instead are derived from a real context. The purpose of a pattern language is not to establish standards but to help understand one another as we build and deliver valuable products.
The biggest issue on software teams is making sure everyone understands what everyone else is doing.
— Martin Fowler
As we strive toward improved understanding through a higher-order vocabulary of patterns, check your thinking against Agile principles. No need to get carried away, as if they carved in a rock and carried down from the mountain by Moses. Be reasonable, yet be principled.
The Standard Canon of Agile
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
In case there is any doubt, “early” means sooner than you think and and “continuous” means a lot more often than you think. And “highest priority” is not intended as a rhetorical statement.
Welcome changing requirements, even late in development.
Deliver working software frequently
In case there was any doubt about the first principle actually being the highest priority.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
In case there was any doubt about the importance of the 1st and 3rd principles.
Agile processes promote sustainable development.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Avoid falling into the trap of simply distilling patterns from experience. It is an interative process, where suggestions of patterns derive from experience, and contemplation of these thought objects leads to new understanding.
To understand is to perceive patterns.
— Isaiah Berlin
David Kovalenko — "Plane in forest"
Taylor Simpson — "Forest stairway"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.