I think many would agree that by far two of the biggest enemies of professional productivity are interruptions and friction.
Classic examples of interruptions are compulsory ceremonial meetings like scheduled daily standups where everyone has to share what they did the previous day; or filling in forms where everyone has to show how many hours they worked on issues.
Examples of friction are: creating issues for every single change made to the code; estimating how long every single issue will take, or having countless issue states.
Most of these come from unfortunate interpretations of Agile like Scrum.
Instead, after having tested and found to be far superior in practice, I adhere to and recommend a common sense methodology, which I call RAPID.
RAPID stands for Research, Analysis, Prototyping, Innovation and Development. Its essence is to ensure that at any point during work, any engineer can identify their activity with either R, A, P, I or D. If they can’t, they have full freedom and autonomy to switch their activity to something they can. Obviously, this setup assumes that your hiring process is designed well enough to reveal a candidate's ability to evaluate various real-life situations. For that, my recommendation is to use the following hiring practice.
RAPID includes, but is not limited to, the following principles:
- RAPID has the primary objective of maximizing focus while minimizing interruptions and friction
- RAPID disapproves ceremonial meetings (standups, retros, grooming or any other rituals)
- RAPID disapproves frequent meetings or any other compulsory ceremonies of any kind
- RAPID disallows meetings where ten people discuss for hours what color a button should be
- RAPID encourages meetings only if and when there are topics that require group attention or discussion
- RAPID ensures your freedom not to join and/or leave any meeting where you don’t contribute or gain
- RAPID requires only two states for an issue: open and closed
- RAPID operates in milestones consisting of pools of issues; that’s it (no “user stories” or anything)
- RAPID gives developers the autonomy to choose issues to work on from the pool
- RAPID does not require estimates on every single issue; only if possible and if makes sense
- RAPID allows and encourages “I have no idea” responses on estimate requests if that’s the truth
- RAPID expects frequent code commits composed of little logical changes
- RAPID operates with an existing pool of test cases that run and grow with each significant commit
- RAPID disallows pre-defined and endless code reviews; only when truly necessary or asked for
- RAPID disallows merge requests to remain unattended for longer than a day
- RAPID welcomes refactoring that reduces LOC while maintaining or increasing readability
- RAPID prohibits weeklong emailing back and forth for things that can be done in ten minutes
- RAPID entails that individuals, not committees, are in charge of most decision points
- RAPID encourages a list of “Always Welcome Optimizations” prioritized based on a measurable impact
- RAPID requires scheduled development pauses to do all approved major refactoring
- RAPID requires scheduled development pauses to upgrade tools to their latest stable versions
- RAPID allows bending any rule in favor of obvious common sense in all the right circumstances
Last, but not least, RAPID assumes an approach with a clear understanding that the efficiency of its principles, practiced either by individuals or teams, cannot grow without Mistakes, Reflection and Improvement (MRI).
