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, but it's important to remember that unlike with civil engineering, where methodologies and practices have been honed and perfected through thousands of years by now, I think we can and should be forgiving to unsuccessful attempts to innovate in software development methodologies since that field is relatively very new to all of us.
So, instead of Scrum, Kanban and the like, after having tested and found to be far superior in practice, I recommend a common sense methodology called 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, I recommend RAPID Hire.
RAPID includes, but is not limited to, the following principles:
Organizational
- RAPID has the primary objective of maximizing focus while minimizing interruptions and friction
- RAPID disapproves frequent meetings of any kind, including ceremonial (like daily standups)
- 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 disallows meetings where ten people discuss for hours what color a button should be
- RAPID entails that individuals, not committees, are in charge of most decision points
- RAPID prohibits weeklong emailing back and forth for things that can be done in ten minutes
- 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 mid-senior developers the autonomy to choose issues to work on from the pool
- RAPID expects junior assistants to mid-seniors for optimal workload distribution
- 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, detailed in RAPID Practice
- RAPID operates with an existing pool of test units 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 pull requests to remain unattended for longer than a day
- RAPID welcomes refactoring that reduces LOC while maintaining or increasing readability
- 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 and dependencies
- 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).
