Thank you for feedback. I should address all these points in the article itself, actually. For now, here you go:
First of all, this isn't based on Scrum at all (I'm not a fan of Scrum, especially, because it's implemented incorrectly in 99% of the places). It's based on XP instead.
Re (1), the teams I'm dealing with are highly collaborative, which means that they pair or mob almost all the time. The reason is that their development process is highly optimised for that (it's faster to deliver something in pair than to do it solo). If the schedule isn't the same for the whole team, and people take lunch at different time, that significantly reduces the availability of people for collaboration, making the whole approach less effective.
Re (2), this works because the PM and EM are also both collaboratively working with the team on the ground as ICs (their % is just a bit different, for example, EM's distribution is 60% IC work and 40% mgmt work - this is because there is a limit to maximum number of direct reports = 6. EM that works with the team on the ground is most effective, because they have significantly more knowledge than the EM that is "in the clouds or in the ivory tower"). Furthermore, the teams have the autonomy to adjust this blueprint via the retrospective (aka reflection workshop) their own process and way of working. What I've seen happen often, is that another developer joins pre-IPMs together with EM — that developer is usually the person who is pairing with the EM on that day. The benefit of this is that everyone gets to participate in the process of refining work items, however, it still maintains the concept of minimum-viable audience wasting minimum possible time.
On top of this, some of the refinement of known & unknown unknowns is actually done via work items, such as exploratory charters and spikes by the team itself. It's just done not in a meeting, but as normal focus or collaborative work. Based on that then appropriate work item(s) can be created to deliver the valuable outcome.
Re (3), Daily planning is not like scrum stand-up, sorry. The purpose of daily planning is to plan the day: that involves who will pair with whom today, and what are the most important things to do or deliver today. And it does have a kanban board where everyone sees the status of items. Usually, people resolve their blockers on their own, via collaboration, or via talking to people, when they arise. However, there is also benefit in trying to fight with the challenging problem for couple more hours and don't call for help immediately (that's how people learn after all). So struggling with the blocker until next morning can actually be beneficial.
Re (4), Yes, I've successfully implemented this is smaller organisations of 10-100 people. I have confidence that it can work beyond that, but, of course, some changes would need to be applied. There is no "silo"edness in the organisations like this because of their high level of collaboration. It's not unlikely to see a pair of developers mobbing with client services, sales, marketing or finance, delivering immense value directly. A few times it was also possible to have "Customer on-Site" which means developers "dabbling" and "prototyping" with the customer or end-user directly.
Re (big picture), I have gripes with synchrony vs. asynchrony. Instead of embracing the asynchronous work — I do the opposite, embrace the synchronous work. There are many more advantages when it's done well, and sync and collocated work has much higher maximum potential for valuable outcomes than async non-collocated one. The reason for this is that it can remove much more wait times and work-in-progress waste from the system, and async non-collocated work increases the number of these. They are detrimental to the flow of value and throughput.
Regarding the productivity of engineers and schedule, the focus isn't on the individual, however, on the team and its ability to collaborate and co-create. So the optimised schedule is to increase the productivity of the team as a whole, and also use the same fixed rigid schedule to build momentum over time.
For the prepared items, there is actually another meeting on Friday, called Pre-Iteration Planning meeting where only Product Manager, Engineering Manager, and other necessary roles join (can be designer or QA if you have or need these). This is where work items are refined, so they are ready for estimation on Monday.
What about the legacy you leave after yourself? Be it invention, great article or a book, children who are better than you, or great businesses or non-profits.
If everybody thought about "just ending in a coffin and everything is pointless", humanity would've ceased existence long time ago.
I’m pretty sure that there are enough people who would be content with such a simple job of maintaining CRUD app. They get less salary, yes, but also they’ll have much less stress, and can focus their energy on other things.
First of all, this isn't based on Scrum at all (I'm not a fan of Scrum, especially, because it's implemented incorrectly in 99% of the places). It's based on XP instead.
Re (1), the teams I'm dealing with are highly collaborative, which means that they pair or mob almost all the time. The reason is that their development process is highly optimised for that (it's faster to deliver something in pair than to do it solo). If the schedule isn't the same for the whole team, and people take lunch at different time, that significantly reduces the availability of people for collaboration, making the whole approach less effective.
Re (2), this works because the PM and EM are also both collaboratively working with the team on the ground as ICs (their % is just a bit different, for example, EM's distribution is 60% IC work and 40% mgmt work - this is because there is a limit to maximum number of direct reports = 6. EM that works with the team on the ground is most effective, because they have significantly more knowledge than the EM that is "in the clouds or in the ivory tower"). Furthermore, the teams have the autonomy to adjust this blueprint via the retrospective (aka reflection workshop) their own process and way of working. What I've seen happen often, is that another developer joins pre-IPMs together with EM — that developer is usually the person who is pairing with the EM on that day. The benefit of this is that everyone gets to participate in the process of refining work items, however, it still maintains the concept of minimum-viable audience wasting minimum possible time.
On top of this, some of the refinement of known & unknown unknowns is actually done via work items, such as exploratory charters and spikes by the team itself. It's just done not in a meeting, but as normal focus or collaborative work. Based on that then appropriate work item(s) can be created to deliver the valuable outcome.
Re (3), Daily planning is not like scrum stand-up, sorry. The purpose of daily planning is to plan the day: that involves who will pair with whom today, and what are the most important things to do or deliver today. And it does have a kanban board where everyone sees the status of items. Usually, people resolve their blockers on their own, via collaboration, or via talking to people, when they arise. However, there is also benefit in trying to fight with the challenging problem for couple more hours and don't call for help immediately (that's how people learn after all). So struggling with the blocker until next morning can actually be beneficial.
Re (4), Yes, I've successfully implemented this is smaller organisations of 10-100 people. I have confidence that it can work beyond that, but, of course, some changes would need to be applied. There is no "silo"edness in the organisations like this because of their high level of collaboration. It's not unlikely to see a pair of developers mobbing with client services, sales, marketing or finance, delivering immense value directly. A few times it was also possible to have "Customer on-Site" which means developers "dabbling" and "prototyping" with the customer or end-user directly.
Re (big picture), I have gripes with synchrony vs. asynchrony. Instead of embracing the asynchronous work — I do the opposite, embrace the synchronous work. There are many more advantages when it's done well, and sync and collocated work has much higher maximum potential for valuable outcomes than async non-collocated one. The reason for this is that it can remove much more wait times and work-in-progress waste from the system, and async non-collocated work increases the number of these. They are detrimental to the flow of value and throughput.