RAPID Principles

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:

  1. RAPID has the primary objective of maximizing focus while minimizing interruptions and friction
  2. RAPID disapproves ceremonial meetings (standups, retros, grooming or any other rituals)
  3. RAPID disapproves frequent meetings or any other compulsory ceremonies of any kind
  4. RAPID disallows meetings where ten people discuss for hours what color a button should be
  5. RAPID encourages meetings only if and when there are topics that require group attention or discussion
  6. RAPID ensures your freedom not to join and/or leave any meeting where you don’t contribute or gain
  7. RAPID requires only two states for an issue: open and closed
  8. RAPID operates in milestones consisting of pools of issues; that’s it (no “user stories” or anything)
  9. RAPID gives developers the autonomy to choose issues to work on from the pool
  10. RAPID does not require estimates on every single issue; only if possible and if makes sense
  11. RAPID allows and encourages “I have no idea” responses on estimate requests if that’s the truth
  12. RAPID expects frequent code commits composed of little logical changes
  13. RAPID operates with an existing pool of test cases that run and grow with each significant commit
  14. RAPID disallows pre-defined and endless code reviews; only when truly necessary or asked for
  15. RAPID disallows merge requests to remain unattended for longer than a day
  16. RAPID welcomes refactoring that reduces LOC while maintaining or increasing readability
  17. RAPID prohibits weeklong emailing back and forth for things that can be done in ten minutes
  18. RAPID entails that individuals, not committees, are in charge of most decision points
  19. RAPID encourages a list of “Always Welcome Optimizations” prioritized based on a measurable impact
  20. RAPID requires scheduled development pauses to do all approved major refactoring
  21. RAPID requires scheduled development pauses to upgrade tools to their latest stable versions
  22. 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).