Remote work should be asynchronous
My thoughts after Arkency - Async/Remote book
Scrum is dead. Really. I think that we just should focus on giving value without these stupid ceremonies. Of course, we can make daily, demos, etc. BUT - is it always needed? Maybe it can be asynchronous? Everything should! In creating some processes or company standards we should think about asynchronous processing of them.
I want to present only a few concepts here from mentioned book transformed by my mind.
So, what about pull requests?
How to become asynchronous when always someone is blocking us with PRs, comments, and doing stuff in general. Then maybe it’s not a good idea, hm? WAIT. HOW DARE YOU?!? PRs ARE THE BEST GOOD PRACTICE ON THE WORLD!
But it’s not. Really. Of course, there is a possibility that someone will come out with piece of crap but… we should bet on fast reactions and fixing bugs. We’re all big boys (sorry girls) and we can be responsible for our changes. In the asynchronous model, we can put a small commit directly to the master branch which is immediately deployed to the production environment ( in the name of the father and son ). But the clue is: Small tasks.
Let’s look at the PR process. We develop some code for a few days. Then we’re creating a pull request. In the meantime, we’re starting something new, but someone did a review, so you have to switch context back to the previous task, reply, change something, and then back to work on the current one task. And it can be repeated a few times. WASTE OF TIME. Instead of it we can just push on the master, copy link to specific commit on chat, exlpain why it looks like that, and so on. Discuss asynchronously on separate fragments, and just change them later. And it can be changed by anyone then. Not exactly by you, because you can have more important things to do at the moment. Isn’t it great? Hmm?
Another crucial thing. Size of tasks. And it’s connected to the pull requests directly. When someone develops some feature about month… there are a lot of things that can work worse than expected, and it takes more time to review such changes. As a result - often reviews are fiction in this case. Yes, people are looking at this, they are frustrated because there are other things to do than spending an hour reading code so… YOLO, LGTM and let’s go on production with this shit. :) Kill me, please.
Communication with business
Everything is on the developer side. And every developer should speak directly with the business. Sometimes, it looks like the following:
Do you remember the deaf phone game? It was funny, and that’s how our corporate world looks like - funny either. Because of what? Because of processes that no one understands, and no one wants to be blamed. And the next topic. Blaming people… I’m going to write something about but to summarize it - DON’T.