Kitchen Rules for DEV Teams!

I moved from 宜家 in Helsingborg, Sweden to work with IKEA IT office in Plymouth Meeting, Pennsylvania in March 2008.

Needed to find an accommodation after initial days of hotel stay. Thanks to HCLTech , hotel stay was complementary for first few days when people moved from one country to another. Found a shared rental apartment not too far from Plymouth Meeting Mall. Checked-out from hotel in the evening so I could settle at the new place and start my morning routine from the apartment. I was tired and thirsty after the move, and wanted to get some water from the kitchen. I was wearing shoes at that time.

As soon as I stepped into kitchen, my apartment mate said: "No shoes in the kitchen!".

I was stunned because kitchen was not kept in best shape in terms of how things were (dis)organized, had tolerable limits of dirt around sink, plus stains on the walls & refrigerator.

"Why no shoes?" I asked pointing out other anomalies in the kitchen that anyone could see from naked eyes.

"These are the rules. No shoes in the kitchen." I was told.

Now, back to IT.

When I started consulting, I met various development teams in the process and started seeing similar behavior. 'We don't do this', 'we don't like that', we have never heard of this or that. Blah Blah Blah. Nothing documented though.

More specifically, when new developers would join the team, existing Devs (or at least one of them) would make most noise about new dev's code quality, communication, etc, etc. It didn't matter how flawed their own Dev processes were, they would happily blame new Dev for missing various "things". 'Things' that popped up every other day. Things that were never documented. Things that were 'assumed' as "standard practice".

I know it from personal experience that each team has unique Dev processes and rules. Their "Kitchen Rules".

Why are we discussing this topic?

For Dev teams to understand why it's important to "Document" your Kitchen Rules.

A. What to write in Kitchen Rules: Basically, create few bullet points (examples below) and create that first draft today if you don't have one already. This is a living document that will evolve over time so don't worry about creating that perfect document day 1.

1. Code Management: Write down how you manage code. You might be explaining this to a new recruit orally. Better to write it down once and for all. For example:

• Take pull from Master and create feature branch.
• Keep pushing code to Git several times a day.

2. Avoid Merge Conflicts: Write few lines on how to minimize merge conflicts. For example:

• Merge code from Master branch to your feature branch at least once each day.
• Merge Master branch to your feature branch prior to opening a PR (pull request).

3. Code Quality Management: How do you manage code quality? Mention best practices. Mention if you use Storybook or Material UI. Add your new Dev to SonarQube if that's what you have been using. Also make a note whether to refactor legacy code or not; need approval from someone prior to touching any legacy code, etc.

4. Environment Management: Document where to find a copy of .env file or database. What steps to carry out when staging goes down due to limited storage issues, for example.

5. Deployment Process: Write down step-by-step process for deployment. Not to mention, don't share passwords, keys or secrets in your documents.

6. Task Management: Mention how you manage tasks. Github, JIRA (not my favorite anymore), ClickUp, Monday, Asana, Trello. Any particular thing you want your new Dev to take care of. For example, change the task status from "In Progress" to "Tech Review" once a PR is created.

B. Where to maintain this? Best place would be WiKi pages within GitHub, or a Google Doc, or wherever your Devs hangout most.

C. Benefits:

1. New Devs or team members (that closely work with Devs) get acclimated with your dev process seamlessly and fast.
2. Your managers or executives know how their team is organized.
3. Super important if you work with offsite or remote Devs.

D. What If I don't do it?

• Frustrate yourself when new hires make repeat mistakes despite your 30 min boring onboarding speech.
• Keep hiring new Devs because you fired the last one who was really smart but didn't memorize your "Kitchen Rules".

..

..

P.S.:

I advise clients on improving team productivity by identifying & removing bottlenecks; and help align Dev teams with Product goals. Book a time to speak: calendly.com/subodh