This essay is full of awful advice and is more about the author venting that their work isn't organized how they like. I would recommend they found a startup an

This essay is full of awful advice and is more about the author venting that their work isn't organized how they like. I would recommend they found a startup and experiment with the kind of structure they think would work best and see how it scales! >No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a healthy portion of “give me some space to do my work.” The author speaks as though they have never been in the situation where their team delivered a product that meets the spec but isn't actually useful to their customers. Agile (what the author means when they speak about tasks/backlogs) doesn't guarantee this problem will be fully solved by doing by-the-numbers scrum or w/e, but the system they are flirting with in this essay is almost certainly worse. It's a complete recapitulation of waterfall/cowboy and adhoc design processes, without the honesty to interrogate why these processes failed organizations large and small. >As I see it, little tasks are born of a fundamentally different management attitude. Small tasks are a not-so-subtle way of saying that all the product vision lies with management. Keep away. Don’t touch. The author is talking, here, about how encountering agile makes them feel. This is not a universal experience. I would reply that we have a division of labor/responsibility because technical personnel are often some of the worst people to speak for the customer, and history has born this out. >Then you went back to your private office (I sure miss private offices, but that is a topic for another day) and fixed a few things. Later, in a weekly status meeting you would tell people how it went — yep, that’s right, no daily stand-ups where you look mournfully at your shoes and admit that you didn’t make any notable progress yet. Once again, the author is telling on themselves If they don't like feeling like they aren't making progress, it's almost always because they aren't motivated or need help. Certain team strutures (e.g. Mob Programming) actually produce incentives for this sort of task-going-nowhere problem to be addressed constructively (also against silo-ing, another perverse tendency that this author implicitly endorses throughout the essay). As an aside, I agree about the communal working space trend in tech being shitty, if you team can't work communally. This is a problem that agile practices are only beginning to address (again, please see Mob Programming for a way to deal with this). >Sadly, as developers, we do it to ourselves as well. Once someone gives us a better title, we are right on board with the program. When a regular developer might have had a chance to do some research or design, we immediately snatch it away for ourselves. This is a philosophical non-sequitur. How are tasks related to snatching design work away from non-architect/technical-lead developers? Any team that wants to spread around design work can address this and whether a team does agile/task-based work has no bearing. >Worse yet, we design every product’s architecture, and expect any deviation to be approved by us first. All that is left are tiny morsels. Grunt work for the foot soldiers once the fun has been stripped away. The author moves and back and forth between speaking as a grunt developer and speaking as an architect/technical-lead, and it's quite confusing. They are also, per their bio, a fan of "organizational self-management". Furthermore: >“I am Amerigo, the product guy. Heretofore, no developer will make product decisions, for they are mine.” >“And I am Ferdinand, process guy. Heretofore, no developer will make process decisions, for they are mine.” >“I Bartolomeu will enforce compliance.” >“I Vasco used to be pretty good at Microsoft Access, I guess I’ll be the database guy.” I feel like you put all of these things together and get a picture of a programmer who I, personally, would be absolutely terrified to allow in front of a customer, let alone expect them to work constructively with other functional stakeholders. For the record: I'm a technical lead in a medium-sized (~150 developer seats, many more non-technical roles) enterprise software organization. Most of my experience is in the enterprise/consulting space and my perspective reflects that. I think the kind of unstructured/responsibility-based approach the author advocates is naive and says more about their problems working with others than it does about how dysfunctional agile can be. I think the main barriers to teams delivering is how to cooperate to deliver consistently and sustainably, and not that rockstars needs to be set free to pursue their own agenda within vaguely defined boundaries of responsibility.