Daily Standup

Are you confused as to whether to do a daily standup or not for your team? Read on why you should.

Daily standups are a hotly contested and controversial topic in the software industry. There are some who actively champion it, and then there are others who detest it. I belong to the former camp, and firmly believe every team should do a daily standup.

One of the primary problems that teams face is information asymmetry. Some members tend not to know what their teammates are up to; this results in individuals becoming islands and a breakdown in efficiency. I can write an entire post on the problems this causes but for some other day. One of the reasons for this is not everyone in the team communicates at the same level; all teams face communication asymmetry.


Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

There is a vast diversity in humans when it comes to communication. Some excel in it; some do not. Efficient and timely communication can make or break teams and are a huge indicator of a team’s success. Standups force everyone to communicate. You do not have the option of not communicating during a standup.

A format I have seen work is going around with each one telling:
1. What they did yesterday.
2. What they plan to do today.
3. Any blockers they are facing which needs immediate attention.

This ensures everyone in the team knows what their teammates are working on.

Apart from information proliferation, this also helps in surfacing blockers. A lot many people do not know when to surface blockers, and they wait for things to go down before yelling for help. Daily standup gives everyone a forum to do it before shit hits the fan. It also allows others in the team to intervene and course correct when needed.

As with any meeting, it is paramount to keep daily standups short and sweet. Do not allow anyone to hijack the daily standup for lengthy or off-track discussions. Do it outside the standup.

One downside of standup is that people who communicate well and efficiently feel penalized and do not see the worth of it. I was in this camp when I was new to the industry, but as I have built teams and scaled organizations, I have become an acolyte of daily standups. If it is of any solace, think of it like taking one for the team and the organization.

Photo by Margarida CSilva on Unsplash

All In

As a young fledgling startup, you should not be building layers of abstraction over the technology that you are using; on the contrary, you should be going all in.

I have talked to multiple startups doing this. The intention is to future proof the product; this should be the least of your concerns during the early days. In your gestation period, you should be spending your waking hours building features to acquire customers and grow. That is what will make or break your startup, not the abstraction layers you create for the distant future.


Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

If you are using MySQL, then go all in on it. MySQL has a lot of features that are above and beyond the ANSI SQL standards. Do not try to be standard compliant and avoid the esoteric non-standard features; try to leverage them as much as possible. It will take you faster to market at the cost of being locked in on MySQL for the foreseeable future. If your startup survives to see the day when MySQL becomes the bottleneck, you will have enough resources and expertise to make the switch. Same applies to cloud providers. Do not try to be cloud agnostic; utilize the features given by your cloud provider to the maximum.

This might sound orthogonal to some of the advice that you might get on the internet as well as sound engineering practices. A lot of these are written for mature companies with established product and revenues, not for young, early-stage startups. As with everything, it is all about context.

If you think about this, it boils down to a simple decision; whether you live in the present and try to maximize for today and the immediate future or plan out for the distant, uncertain future. A young startup, trying to make its mark on the world, should do the former.

This is a bit counter-intuitive and becomes challenging to do if you have a mindset that is more attuned towards a systematic way of thinking and doing. A lot of things with startups are counter-intuitive and go against the grain. If not, would it not be a cake walk?

Photo by Nancho from Pexels.

Make It Small

“Make it large” is the mantra these days, but when it comes to releasing software, think the opposite, make it small. The secret to a successful release is to break it into numerous small deployments; this serves a dual purpose, minimizes risk as well as gives you enough leeway to fix bugs before it negatively impacts end users.

Never wait for a feature to be complete for deployment. Break it into multiple smaller chunks and keep deploying these to production even though no one will be using it. Smaller deployments always win over one big bang deployment. Longer the code runs in production, more data points you have to analyze and take corrective steps.


Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

If you can test with real users without them knowing, there is nothing like it. If you put your mind to it, you will always figure out a way to do this. Taking an example, let us say you are building a chat feature for your application. You can stealthily release it without informing your users and send dummy messages on their behalf. The user does not see any chat related functionalities, but behind the scene, you create dummy messages and send them to one another. Apparently, this is how Facebook tested their chat before launch; this allows you to check your feature realistically in ways it will be ultimately used.

Another trick is to log the action without actually carrying out the intended side effect. Say for example; you are introducing an API rate limiter. As a first step, start logging whenever an API call hits the rate limit threshold. During this phase do not block the calls, the idea is to emulate the result; this lets you test out the feature with real traffic and fix any bugs before it starts negatively affecting your API consumers. Once you are confident of your approach, you can roll out the feature where you block offending callers.

Phased rollouts is a life saver. Release features to a small set of users, keenly observe your application and gradually ramp up to 100%; this minimizes the impact of bugs and lets you catch them early.

Another lifesaver is feature flags. The idea behind a feature flag is simple; you put all your features behind an on-off flag which you can toggle if and when needed. The ability to turn off features during their early lives gives you a lot of flexibility and room to maneuver and improvise.

If you are working on refactoring or replacing an infrastructure component, never do a stop the world cut off. Always run both the systems in parallel and only once you are confident of the new approach, do the switch over. Say, for example, you are moving your data source from MySQL to Mongo, start by writing to both the datastores in parallel. Then change your application to work with Mongo while still keeping the option to fall back to MySQL if needed. Put this behind a flag which you can toggle. Only once you are confident of everything working with Mongo, pull the plug on MySQL.

The common thread that holds all these strategies together is to plan your deployments such that they are small and gradual; if something goes wrong, it is not catastrophic. You increase the scope gradually as you observe and gain confidence.

As they say – Risk is what’s left over when you think you’ve thought of everything. A bit of planning goes a long way in reducing risk as well as giving an excellent experience to your users.

Photo by Magda Ehlers from Pexels

Knowing Versus Doing

Over-engineering is ripe in the software industry; this mainly manifests in three ways:
1. Needlessly complicated design.
2. Lift and shift engineering – Picking up technology and practices from other places without understanding the context in which it was developed.
3. Being trendy – Using frameworks and languages that are currently in fashion irrespective of whether one needs it or not.

I have written about this before.

Please do not take this prose as an argument for being sloppy and building crappy products.


Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

I firmly believe one of the reasons why this occurs is that people confuse knowing with doing. You being aware of something should not force you into using or implementing it. You might have a personal inclination towards a language or a framework; you might even believe that it is the best in the world, but that does not imply you rewrite your currently well-working production application in the said technology. You come across something new, and shiny does not mean it has to be part of your application stack.

When we see something novel and trendy, our brain actively tries to figure out ways in which we can make it a part of our lives.

Another arena where this plays out is in doing things if and when needed. Because you read a blog post touting Redis as the next best thing to sliced bread should not make you go about slapping Redis as a cache in front of your data stores. Your data size might be tiny that it entirely fits into main memory. Achieving five nines of reliability is a daunting task which takes a lot of engineering and effort. As a geek, it is a fascinating problem to work on, but your application may not need it. Just because you are aware of what others are doing to achieve this does not imply you too embark on this path.

If you ponder over this, you will realize this behavior is not only restricted to work but plays out in our personal lives too. When we come across something new and exciting in any domain of life, we try to adopt it irrespective of whether we truly need it or not, and when we do it, we go way out of line in justifying its usefulness to ourselves.