DevBlog about human aspects in programming
To delete all documents from a Firebase collection in Firestore we need to get the collection, iterate over its elements and delete each one of them:
const db = new Firestore({
projectId: "projectId",
keyFilename: "./key.json"
});
db.collection("collectionName")
.get()
.then(res => {
res.forEach(element => {
element.ref.delete();
});
});
Participating in an overgrown scrum team is a fascinating experience. It allows us to observe how the framework collapses under its own weight.
Basically, scrum consists of meetings. Daily stand-ups, backlog refinements, sprint planning, review, and retrospective. These meetings, in theory, can consume even 22.5% of developers’ time. That’s a lot. But as always – it depends.
Observation 1 – meetings get longer
Let’s start with a daily scrum. It should last no longer than 15 minutes. As long as the team is just a few developers big – it’s easy. But when we have 15 devs we can give everyone only one minute to speak. It’s pretty impossible. Either we will destroy the idea of the daily meeting – where the team members can properly describe what they worked on and ask for help (by forcing them to speak extremely short) either we’ll extend the time. In the team of 14 developers, I’ve seen daily scrum to grow up to 25 minutes.
Exactly the same is the situation with every other meeting. But in case of refinements or sprint review, it’s getting even worse because these meetings are naturally longer than daily scrum.
Observation 2 – meetings become full of things you don’t need to hear
As the team grows, the scope of work grows. Naturally – as in any big enough group – the subgroups form up. It can be any kind of division – front-end and back-end devs; people who work on feature A, and another group working on feature B; Java, and JavaScript programmers. When they work on the everyday tasks they almost don’t talk to each other unless they need to discuss some API or contract which is necessary for the parts of the system to communicate. But if the scrum team doesn’t split they’re forced to participate in the meetings together.
Then you find yourself in a meeting where half of the time is spent on discussing the things you don’t need to hear. You’re let’s say a JavaScript developer and last 30 minutes of a meeting was a discussion about back-end, or you’re developing database structure while implementation of the UI of the system is estimated.
Observation 3 – productivity plummets
You want to code. That’s why you became a software engineer. You like to focus, you love to create lines of instructions. This is also why, all in all, you’re getting paid. You automate processes, therefore, people don’t need to be employed to make them manually and the company is more effective. The money saved on automation goes to your pocket. Everybody is happy.
Unless you can’t code.
When the length of scrum meetings get longer it consumes your coding time. When the meetings get boring it consumes your mental energy. You become less productive. Not cool.
That’s why Scrum guide recommends a scrum team to be between 3 and 9 developers. Even if it seems difficult to divide – it’s necessary. The alternative is a small crowd of unhappy, ineffective developers.