Cargo cult in software development
Recently, I see many examples of how technical project managers follow the canons of the Cargo cult when developing and managing projects, instead of introducing entities as they are really needed, and building the process itself based on current needs, available resources and qualifications of performers. We will talk about how to identify such a Cargo Cultist and what risks they carry for the project.
To my natural question to one such project manager — how tangible the benefits of this event, he honestly answered — “I don’t know myself.” Despite some advantages for the team, part of which worked remotely, discussions inevitably boiled down to “Yesterday I wrote code, today I write code, and tomorrow I also plan to write code, and, well, I also fix some bugs.” As a result, we have minus half an hour from the time of each team member.
Some advantage for remote workers is daily communication with the team, for some of them this is very important. In my opinion, the benefit for development process from such daily discussions is rather small, since the main task of daily standups is to convey to everyone information about the current state of development, plans for the near future (from a week to a month), discuss some issues that interest everyone. Very often, such discussions turn into discussions of some niche issues that are of interest to a couple of people, and the rest begin to get bored and wait for it to end. This should certainly be suppressed and discussed later in a narrower format. The current state of development and plans are very important, but it is enough to discuss them once a week or even less often, depending on the speed at which the team works.
