So, its “take Scrum, then eliminate everything that Agile gets right, then treat professional knowledge workers like they were working on assembly line”, plus, bonus, be sure to ritually invoke a declaration that each meeting is an “effective” one.
Does this really acheive its goals that 92% of IC work time is “focus and collaboration”? Maybe, if you define those loosely enough. Does it foster effective productivity? Probably not. Specific notes:
(1) Everyone has the same fixed start, ending, and lunch times. This isn’t justified anywhere, and doesn’t seem to contribute to the goal in any way. Maybe makes it slightly easier to arrange necessary collaboration, doesn't contribute to the the total alotment of focus+collaboration time. Drops efficiency of focus time, most notably because forcing everyone to a tightly synchronized schedule means people are “at their desk” because its what the schedule says rather than breaking for lunch or even end of day earlier or later than a fixed schedule would indicate because of how convenient breaking points in flow work occur.
(2) Pulling ICs fully out of the process of assuring work items are properly prepped (no “backlog grooming” meetings, or team members doing similar work out of the meeting context.) Narrowing engineers view of the pipeline, eliminating their early feedback on work items and how to structure them, and putting this function (as you note in another comment, though not the main article), with a reduced time allotment in the hands of a group whose essential participants are the Project and Engineering Managers is... well, as someone wbo hates grooming meetings, I still think this is a step back. Yes, most prep of work items shouldn't be in dev team meetings. At the same time, the dev team should be involved, and shouldn't be seeing work items at the Sprint, er. “Iteration” Planning meeting, where they spring fully formed from the forehead sof manager-gods. Sure, that way may mean a greater share of time spent working on the work items, but it also means the work is more poorly directed.
(3) Probably the worst manageritis, despite a nominal focus on maximizing focus+collaboration time, you've retained from Scrum the Daily Meeting that Should Have Been a Kanban Board and the tradition of “Why deal with an impediment stopping productive progress today when you could have a regularly scheduled meeting tomorrow instead”.
(4) Not super critical, but this seems to assume there are only two levels at which meetings affecting ICs occur: dev team and whole company, outside of a very small company, this is probably a bad sign of an extremely siloed organization.
Big picture: Improving flow and productivity isn’t a matter of treating engineers like horses with blinders and increasing synchronization, its about embracing asynchrony and letting engineers own the work and the workflow. And, while avoiding unnecessary and unproductive meetings is important, taking miaximizing hours at work without meetings as a goal is... well, not an exception to Goodhart's Law.
Does this really acheive its goals that 92% of IC work time is “focus and collaboration”? Maybe, if you define those loosely enough. Does it foster effective productivity? Probably not. Specific notes:
(1) Everyone has the same fixed start, ending, and lunch times. This isn’t justified anywhere, and doesn’t seem to contribute to the goal in any way. Maybe makes it slightly easier to arrange necessary collaboration, doesn't contribute to the the total alotment of focus+collaboration time. Drops efficiency of focus time, most notably because forcing everyone to a tightly synchronized schedule means people are “at their desk” because its what the schedule says rather than breaking for lunch or even end of day earlier or later than a fixed schedule would indicate because of how convenient breaking points in flow work occur.
(2) Pulling ICs fully out of the process of assuring work items are properly prepped (no “backlog grooming” meetings, or team members doing similar work out of the meeting context.) Narrowing engineers view of the pipeline, eliminating their early feedback on work items and how to structure them, and putting this function (as you note in another comment, though not the main article), with a reduced time allotment in the hands of a group whose essential participants are the Project and Engineering Managers is... well, as someone wbo hates grooming meetings, I still think this is a step back. Yes, most prep of work items shouldn't be in dev team meetings. At the same time, the dev team should be involved, and shouldn't be seeing work items at the Sprint, er. “Iteration” Planning meeting, where they spring fully formed from the forehead sof manager-gods. Sure, that way may mean a greater share of time spent working on the work items, but it also means the work is more poorly directed.
(3) Probably the worst manageritis, despite a nominal focus on maximizing focus+collaboration time, you've retained from Scrum the Daily Meeting that Should Have Been a Kanban Board and the tradition of “Why deal with an impediment stopping productive progress today when you could have a regularly scheduled meeting tomorrow instead”.
(4) Not super critical, but this seems to assume there are only two levels at which meetings affecting ICs occur: dev team and whole company, outside of a very small company, this is probably a bad sign of an extremely siloed organization.
Big picture: Improving flow and productivity isn’t a matter of treating engineers like horses with blinders and increasing synchronization, its about embracing asynchrony and letting engineers own the work and the workflow. And, while avoiding unnecessary and unproductive meetings is important, taking miaximizing hours at work without meetings as a goal is... well, not an exception to Goodhart's Law.