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.
1. I have implemented the company browsing feature
2. I have made it available without signup/login (partially—you’ll see companies/locations and how many entries they have each, and be able to navigate to these company pages, but from there to see numbers, you’d need to signup/login).
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.
It’s not anonymous in a sense that I’m going to see your linkedin profile. I could have found your profile on my own if I wanted to (that’s what LinkedIn is for in the first place).
What’s important is that I’m not going to see the numbers you entered.
Also, since I’m verifying every registration (in half-automated/half-manual way), and it takes about 20 seconds to do the verification, I cannot possibly remember who I’ve seen and what profiles do they have. (simply because I’m human).
Additionally, what is important is for what purposes you allow me to process your data. And the only purpose for this LinkedIn data is to verify your company name, job title, and location. Once that is done, the data gets removed or disassociated from your account, which means that it can no longer be meaningfully processed (anonymized), and since I don’t have your permission to do any other types of processing—I won’t.
EDIT: So what is anonymous are the salary numbers—and that is what I’m talking about on the landing page.
There was a problem with some special characters (they were not included in validation), and password manager would generate a password that is pretty good, but doesn’t have special characters I’ve initially chosen.
Now, I’m including most special characters, so it should work.
PS: Also, the pre-flight validation now includes special character check too, so you can see the validity real-time instead of after you submit. (This check was not originally included on the client-side, only on the server).
No third-party scripts are used except for Live-Chat. And even that one is only loaded when you click on the Live-Chat button.
Maybe pi-hole doesn’t like "cookie-banner" class/id of the cookie banner component?
EDIT: there are some default landen.co scripts (for landing page only), but they are fairly standard and shouldn’t be invasive for some extensions to block them…
I agree with this. No matter how much I love the company, their mission, or people I work with, it’s not healthy to work 7 days a week and 10h a day for the company that you are not an owner of. Boundaries between job and life are flexible, but not as much.
I’d rather spend 10h a day 7 days a week pouring efforts into my own assets, or towards my vision, and not for someone else’s assets or vision, especially if I have no say and stake in the high level decisions (like sale of the company).
This is a disgusting business model. If any of my products (that are in similar domain) succeeds, I’ll never turn to this model!
Also, I hate ads too.
For this business domain, that leaves a business model where "power users" of the product can get more features, or more access, or more detailed data for a premium fee.
Are there even more alternatives? What do you think?