We know and use the phrase “Best practices.” Best practices are procedures accepted or prescribed as being most effective or correct. We welcome them because experienced industry professionals, thought leaders, our own experience, and mentors share them as proven correct and most effective.
Having learned these best practices and taken them to heart, seeing someone or teams go away from them may seem odd or wrong. But studying why companies would slip away from them will almost always triumph over fundamental attribution error.
This is what we attempt to do in this article: we will cover some common best practices and why would engineering teams not utilize them. We will also go into why some of these “best practices” might actually become bad practices.
We will cover:
Stand-up meeting (Daily scrum)
While Stand-ups offer immense benefits, some development teams do not have them for the following reasons:
- Stand-up Meetings Inhibit Innovation: In this research, Professor Andy Wu of Harvard business school explains that having fewer meetings, letting people work on their own, and dig deep into the problem at hand brings about innovation.
- Stand-ups can be a waste of time. From this article by geekbot, some teams say daily stand-ups are unproductive because of:
- The huge time cost involved scheduling a meeting time that works for everyone (time zone differences/calendar clashes).
- The “Blockers” question often leads to problem-solving during the meeting without any follow ups on it
- Discussing updates that are unrelated to other people’s work.
- We know from our community for Engineering Managers that standups can go wrong:
- Developers see Stand-up as another means of micromanagement. Someone on the community chat asked: “Why do developers see Stand-ups as another means of micromanagement?” citing that it costed them the loss of two key developers.
Daily scrum (stand-ups) are great, but it becomes a bad practice when it doesn’t help the development team work better and when it feels like a waste of time. - Using Stand-ups for reporting status. Another engineering manager in the community: “A Daily Stand-up is there to help members communicate and foster collaboration, not to report status.” The scrum guide says Daily Scrum (stand-up) should focus on progress toward the Sprint Goal and produce an actionable plan for the next day of work.
- Developers see Stand-up as another means of micromanagement. Someone on the community chat asked: “Why do developers see Stand-ups as another means of micromanagement?” citing that it costed them the loss of two key developers.
“Never discuss sprint items on 1:1’s”
Here at Zumvie, we are building the best software for engineering managers to manage their 1:1’s with their direct reports. We have learned that people tend to fall in multiple buckets when it comes to 1:1’s:
- Never discuss anything sprint-related on the calls and make the 1:1’s purely about building a relationship and growing the developer.
- Some sprint and work-related items, the rest on the developers’ growth.
- Mostly work and sprint related, there’s almost nothing else.
While in general 1:1’s are meant to be to grow the developer and ensure they are happy at the organization, none of the above-listed items is a bad way to use 1:1’s. Some of the reasons why people shift away for the “designed reason” of 1:1’s might surprise you:
Culture of non-openness
In some countries and regions, the culture is that of no-openness. This means developers don’t open up and let the issues be known in group calls during standups or other designated times.
It’s possible to fight this if your team has just one or two such “non-open” developers, but if the majority of the team is or you live in a region that has such a culture in general, there’s almost nothing an engineering manager can realistically do to change anything in the team’s behavior.
No top-talent
Not all companies can hire or are in a position to attract the top talent that will rigidly follow best agile and scrum practices. This means that the rest of the culture in the company might be broken and processes not followed Discussing sprint-related issues on 1:1’s is one of the most effective ways to fill the gaps and it works.
Last resort
If an engineer brings up sprint-related issues on a 1:1 call with his engineering manager, there sometimes will be no other option than to let them. While there might be a better time or a designated team meeting to bring the issues up, managers are aware that some developers will be shy or too uncomfortable to bring them up in public. So they won’t.
In these situations, the 1:1 becomes the only option and the only way to get the information out of the developer.
Always write code comments
Comments are an essential part of writing code. We write Comments to explain why we wrote a certain piece of code. While starting out writing software, developers learned to always comment on their code. Commenting is a best practice because “your future self or the next developer will thank you for it.”
However, sometimes developers don’t apply this best practice when:
- Faced with deadlines: Development teams in the habit of writing comments may come under pressure by business teams to deliver quicker with technical debt.
- “Good code is self-documenting”: Yes, that is true. Some teams write little to no comments. Yet this doesn’t change the fact that commenting on code is indeed a best practice.
While commenting is a best practice, in some instances, it becomes a bad practice:
- Inaccurate/Misleading comments: Obviously, developers don’t intentionally write inaccurate comments. But it looks great when we write a good comment explaining the how of a function (a piece of code). Still, if changes are made to that function, the comments become inaccurate or misleading. The code works, all tests pass, but those misleading comments will cost your team or future developers during maintenance.
- Too many comments: It is good to write comments, but it doesn’t mean we should comment on every code in the codebase. Some codes are obvious, and too many comments are just a waste of time and resources.
Find your own best practices
These are but three examples of the best practices. There are hundreds of examples in the world of software development. TDD (Test Driven Development), BDD (Behavior Driven Development), the Hungarian Notation, and so much more.
They are proven correct and most effective, but that doesn’t make them universally the best.
The real question we should be asking ourselves is “What could we do to make things better for us?”.
It does not mean that you must go away from universally proven and accepted practices and change everything. But every team needs to review its processes and think critically about what’s best for them. Just because it’s widely known as a “best practice” doesn’t mean it should work in all situations.
We can think about what we are optimizing for: measure the other important aspects of the team that the “Best Practice” might adversely impact. Review the situation and adjust the “best practice” accordingly.
