I would not say so. In agile, individual developer does not have personal responsibility for anything. In this system, individual person had own task and was accountable for that task completion. It also sounds like they were working independently and wouldn't get help unless they asked for it.
"I will fire you if deadline is suddenly not met and no one else is there find out before if you don't say so" is on the opposite extreme from agile "everything is collective task, we check up on you every four hours and you are neither autonomous nor responsible".
In agile, individual developer does not have personal responsibility for anything.
Where in the world do you get this idea? For one, there is no such thing as "agile", in the sense of a prescriptive methodology that would make such a declaration. There are just individual methodologies that claim varying levels of adherence to the Agile Manifesto[1]. And even then, the popular "Agile" methodologies like Scrum, XP, etc. never say that no one has personal responsibility for anything. Some say that teams are self-organizing and that you succeed or fail as a team, but I think everybody understands that that later part doesn't mean you can just come in and stare at the walls all day with no consequences.
we check up on you every four hours
If someone is "checking up on you every four hours" it's almost 100% certain that whatever process you're using has absolutely nothing to do with "agile".
Are you sure? Daily standups = checking up on you every 8 hours, and then you have tons of checkups in-between. Retros, sprint planning, ticket management. Agile methodology is designed for a tech lead to know what each member of the team is doing.
Agile methodology is not "here's a large task, I don't want to hear from you again until it's completed".
None of that stuff is "Agile". Those things are artifacts / ceremony related with specific methodologies which are only "agile" to varying degrees. Read the Agile Manifesto, there's almost nothing prescriptive in there at all.
Agile methodology is designed for a tech lead to know what each member of the team is doing.
That might be the case for some specific "agile" methodology, but if there's a core essence to Agile, it's about embracing and responding to change... nothing to do with tech leads.
How, exactly, is embracing and responding to change going to happen if there's not frequent communication? What form of agile methodologies have the developers going off on their own for weeks without oversight? How do they 'respond to change'?
A strict literal reading of the agile manifesto doesn't include daily standups, yes, but if you read it at anything other than the most superficial level, frequent communication is necessary.
> How, exactly, is embracing and responding to change going to happen if there's not frequent communication?
Frequent communication doesn't have to be synchronous, prescheduled, or in-person, though, and it doesn't have to be through a heirarchy (team lead).
Also, the phrase "Agile methodology" is almost an oxymoron (and absolutely incorrect in terms of most of the methodologies it is applied to); a development methodology in the usual sense cannot be Agile, though a team's higher-level methodology that controls choice of and change to the development methodology can be.
I didn't say it had to be any of those things, and mentioned ticketing as well, which is none of those things. The comment I was responding to was about being checked-up on frequently. And regarding tech leads, once you get above the size of a single very small team, how many of those don't have some form of technical lead?
Besides, the Agile Manifesto explicitly states at least one form of daily interaction: Business people and developers must work together daily throughout the project. Having this in the list and then pretending that having standups are the functional opposite of "what Agile really means" is just nonsense.
Every time I see one of these "Ah, but Agile doesn't have to be that way", it makes me think of lynx and w3m. There's the way the majority of browsers work, and then there's ones like these. Yes, you can make the correct technical argument about what a web browser is, and then there's the way that almost everyone thinks of when the word 'browser' is used. File a bunch of bugs about how your front-end is failing in w3m, and then sit back and watch the WONTFIXs roll in.
That was my experience with agile. So, on earth in software companies :). But theoretically, agile methodologies I studied were about team responsibility.
"Some say that teams are self-organizing and that you succeed or fail as a team"
That is opposite of personal responsibility. There is very little space for making individual decisions and being responsible for them. If you like, you can force your vision, but whole team will be responsible if it was wrong - not you. If you like, you submissively accept other peoples opinions and it will still be the same thing accountability vise.
"I think everybody understands that that later part doesn't mean you can just come in and stare at the walls all day with no consequences."
No you can not and that is good thing. However, it is totally different then case described in the article where employee had to manage own long term tasks without any supervision at all. Article implies that employee was responsible for communicating delays without anyone actively asking about it.
"If someone is "checking up on you every four hours" it's almost 100% certain that whatever process you're using has absolutely nothing to do with "agile"."
Tasks are supposed to be split into small tasks of maximum of half day length, you report on them as you go, there is daily standup and progress is supposed to be evaluated every week.
That is opposite of personal responsibility. There is very little space for making individual decisions and being responsible for them.
I see it as a continuum, with a lot of room between "absolute autonomy and no responsibility to the team" and "slave-like adherence to someone else's position". In between there is a place where you take a position and have to sell the rest of your team on it and then once everybody buys in, the whole team does own the decision.
But I think here we're talking about design decisions, architecture and what-not. What I mean earlier was more about responsibility for actually delivering the things you say you're going to deliver. So if, on your self-organizing team, you volunteer to take on the task "Write Fromgizzit-A I/O module" then there is indeed responsibility around actually delivering the code in question, as opposed to coming in every day, spending all day reading HN, and not delivering anything.
Whole team owns decision is precisely lack of accoutability. They might have agreed, they might have choice between pretending to agree and circularly discussing the same detail for hours, they might have been afraid to disagree for political reasons. They might not consider it important. They might have been introverted geeks uncomfortable with heated discussions.
If you and code reviewer ends up not agreeing on something, then you are not responsible for delivering it.
But more importantly, agile tasks are max half day long, so your inactivity would be very fast recognizable and responsibility is limited by that. You are not responsible for communicating issues nor recognizing them, you are not responsible for overall deadline nor anything like that. The only thing you are responsible for is not slacking for half a day, everything else is taken for by other people.
"I will fire you if deadline is suddenly not met and no one else is there find out before if you don't say so" is on the opposite extreme from agile "everything is collective task, we check up on you every four hours and you are neither autonomous nor responsible".