Optimizing Focus and Collaboration Time of IC to 92% in Software – Feasible? | Hacker News Reader

Optimizing Focus and Collaboration Time of IC to 92% in Software – Feasible?

1 pointwaterlink7 comments

I recently wrote an article outlining an approach to achieving a 92% focus & productive collaboration time in software engineering. It's a strategy involving cutting meetings, aligning schedules, and more. I'd genuinely like to know what fellow engineers and managers think about these ideas. Have any of you tried similar tactics? What were the outcomes?

https://10xsoftwareengineering.com/maximize-focus-collaboration-a-92-productivity-guide-for-software-engineers/

View on HN

Not a fan of this - the core assumption seems to be that engineers aren't productive because they're just not paying attention to their schedule, so setting a fixed schedule like they're in elementary school again will "make them more productive".

It also seems to require some sort of Agile gnomes to do the grunt work of planning, because the 55-minuute weekly planning meeting handwaves "prepared work items" into existence.

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.

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.

MBAs demand rigidity in the creative process while they roll a 5d20 to come up with the percentage.

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.

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.

Updated the post accordingly and also covered the Goodhart's law concern.

Reply on news.ycombinator.com