A developer team’s working environment. What is it and how do you make sure it doesn’t break down?

I call this BPSD: Basic Processes for Software Development. ENJI helps teams beyond software development, but since it all started with software, we’re going to talk about it. That means we’re going to touch upon the fundamental processes a team of programmers needs to establish to increase the chances of regularly achieving their goals. Any business and project sponsor is going to want this as they are, as it goes, paying for the meal.

Let me give you the most basic of basics (not if you want, but that you must):

• Daily asynchronous stand-ups in a group chat, so-called “written stand-ups”.
• Daily worklogs for the tasks you are working on. Here’s a tweet for those fierce opponents of worklogs out there who love Uncle Bob. Worklogs are necessary to understand where your time is going and how your plan compares to the facts. This means that the tasks you are about to work on need to be evaluated. Let me remind you that time today is the most valuable asset we have and is not renewable.
• Any work is conducted within the framework of a ticket in a tracker (a task with a description in your task tracker: Jira, Asana, Trello, Basecamp, ClickUp, Notion, Redmine, Sharepoint, etc). If work has come up but there is no task, then we first describe the task, change the status to “In progress” and then start to work. I suggest those who like to do lots of things at once that are heavily fragmented reflect on this question: “Am I doing project work or just on support?”
• Code or any other artifact that you commit and place in the repository should be connected with the number of the task that you were working on. This will help you better understand later what each line of code or documentation is referring to. It works like magic to reduce the time you need to explain this or that decision in your product.
• Your project has CI/CD и collects DORA metrics. CI/CD is strict enough to not allow code into the main branch without any basic checks, like linters.
• Send a daily basic status report to your group communication channel with your developers, stakeholders, and everyone else about what the team did yesterday.

This foundation lets a project sponsor see clearly that the train is moving. Of course, it doesn’t answer any questions about achieving goals, but Enji isn’t a silver bullet. It only helps to create the necessary environment for your team to maintain focus and understand the framework and restrictions. To an inexperienced coder, this may seem like a “tax on development”, but a seasoned engineer clearly understands and recognizes all the benefits these rules bring in the span of a year or half a year of work on a project. Because none of us wants to become a hostage to our weirdly written product, right?

The rules above do reduce the risks of creating something that will later be difficult and expensive to support. They do reduce the “onboarding cost” metric to hire people from anywhere without keeping them in an office under the supervision of a boss.?

Let me remind you that these are the basics. There should also be an unlimited amount of other rules surrounding them that must be adapted to the project depending on its speed, risks, team, values and culture, development challenges, and so on.