The unpleasantness of default dev process
For CI/CD, IDEA, coding language, or cloud infrastructure, we all make certain to be on the latest and greatest available. Unfortunately for dev process most teams end up on very old defaults.
For a non-coding manager that default is Scrum. Scrum is better than handing developers a specification so detailed that it might as well be code. Such a spec is invariably filled with guesses or an entire wrong direction.
However, Scrum usually starts by setting a product direction in stone and then proceeds to hand out small specifications every sprint. The dev team’s input is mostly excluded and that’s crippling for the product.
For developers able to choose their own process the default is “nothing” - just do whatever seems right without thinking much about process.
“Nothing” uses the same 30-year-old tools as Scrum - tickets, chat, and meetings and there is a lot of pressure to get coding. So the result is either a Scrum like bunch of meetings or no clear team opinion on what is being implemented.
Bias acknowledgement: your new dev process should run on Uclusion.
Process without formal approvals, questions and suggestions is unpleasant
Ongoing team opinion is the best defense against code factory. Not rubber stamp the PM, not customer X asked for it, not this project was socialized before we started it, and not fait accompli.
Traditional dev process formal approval is code review, planning meeting, or a specification. Unfortunately, code reviews are late in the game to regulate how and way, way too late to regulate what.
Planning meetings have a number of problems, described here, that usually result in just rubber stamp approval.
So some teams write up an entire spec ahead of time and get the questions and suggestions addressed in it. This is the much maligned “waterfall” approach where one ends up doing the equivalent of a code review on a much less precise language.
The other problem with waterfall is planning fallacy:
The planning fallacy was first proposed by Daniel Kahneman and Amos Tversky in 1979. In 2003, Lovallo and Kahneman proposed an expanded definition as the tendency to underestimate the time, costs, and risks of future actions and at the same time overestimate the benefits of the same actions. According to this definition, the planning fallacy results in not only time overruns, but also cost overruns and benefit shortfalls.
The key phrase there is “benefit shortfalls”. Once you write and approve an entire spec it’s difficult to turn back from doing a project with insufficient ROI.
Nor is chat or team meetings any better for questions and suggestions. They break up the day in a way that makes coding difficult, get back answers that are not thought through, and incomplete assistance does not show in any tool as part of status.
The software ROI problem has no easy solutions, but using a tool with formal approvals, questions, suggestions, reviews, estimates, and blockers is better than generic solutions with little consideration of collaboration.
Process without specifically designed tools is unpleasant
Tickets / Kanban boards, meetings, and chat are general purpose tools not designed for dev process (see link above Kanban boards were actually designed for 1970s factories). You can still use them for dev process, but it’s like building for production from your laptop.
Many developers hope “release early, release often” is a magic bullet but not if it skips team opinion to be guided solely by customer complaint. Coding the wrong thing or the wrong way has an enormous impact on a development team or sometimes an entire organization. So why does task management software not try to help avoid wasted code?
Project management systems are designed to track certainty. This ticket with this date and no mechanism to change that date, another requirement of a good dev process. Such systems don’t track approvals, questions or suggestions (except as unstructured comments) and opinions on them, because they don’t admit ambiguity exists.
What software development process actually requires is a system designed to track and reduce ambiguity. Such a system generates notifications for the team to voice opinions and make decisions. Keeping track of all of that administrivia in meetings, chat, and ordinary tickets is not only unpleasant - it’s impossible.
