RAPID Principles

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 such unfortunate interpretations of Agile as Scrum or Kanban. Companies that introduce these often want to increase the productivity of their worst performers, but only end up alienating and eventually losing their best performers.

Now, it's important to remember that unlike with civil engineering, where methodologies and practices have been honed and perfected for thousands of years, software engineering has only been around for a few decades, so we can and should be forgiving to even the most unsuccessful attempts to innovate in methodologies and practices in this area. But what we shouldn’t do and what is downright stupid is to stick to something that clearly doesn’t work — at least not for everybody, not for every project and not in all circumstances.

So, instead of Scrum, Kanban and the like, I recommend a common sense methodology called RAPID. Having tested it on a few projects, I and the other participants have found it far superior both in theory and in practice.

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, I recommend RAPID Hire.

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