8 ms·

"I like doing stuff without coordination with my fellow co-workers or towards to goal of my program/business." I can't count the number of times I've heard thi

"I like doing stuff without coordination with my fellow co-workers or towards to goal of my program/business." I can't count the number of times I've heard this argument by SWEs who think their job is just lines of code vs accomplishing the business goals of a program that pays them. It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it."

snarf21 5y ago
Well said. Afaik, people aren't getting compensated by LOC * $X. Sometimes the value to the team/product/company is higher by going to pointless meetings than it is by being a code monkey in your basement. No process is perfect but I can't even count the number of man years of wasted and unreleased code because there was no coordination.
- ebiester 5y ago
  I would argue that pointless is a key modifier here. There are many meetings that are valuable, but they are valuable because people put effort into making that time valuable outside the meeting. Meetings should prove themselves.
commandlinefan 5y ago
> think their job is just lines of code vs accomplishing the business goals That's... not what he said at all. "Getting stuff done" means accomplishing business goals more than it means lines of code, so you're very nearly accusing him of saying the opposite of what he said. Feel free to go into the essay and search/replace "getting stuff done" with "accomplishing business goals" - it still makes sense and is completely accurate. Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable.
- vannevar 5y ago
  > Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable. Where did you get that idea? The Agile Manifesto literally says: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Scrum is deliberately incremental precisely because it's designed to accommodate continuously changing business requirements that are NOT predictable.
  - ahelwer 5y ago
    Nobody cares what the agile manifesto says. The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager. Of course, no developer actually makes uniform incremental daily progress so this really just turns into a demoralizing exercise in lying about what you did the previous day, punctuated by underselling the days where you actually got quite a bit done. Then you tune out as everyone else goes in their turn giving updates on something that doesn't affect what you're doing in any way whatsoever. The best weeks are when the manager goes on vacation so you don't have to put up with the daily bullshit. Also, every manager swears their scrum isn't like this. And every one of them is wrong.
    - worik 5y ago
      > so this really just turns into a demoralizing exercise in lying about what you did the previous day What depressing places you worked. I have worked once at a firm that had a daily meeting of developers. It was very useful, no expectations, we kept each other informed. Why would you lie to your comrades? I can guess answers to that....
      - ahelwer 5y ago
        See how many days in a row you can say "I didn't make progress yesterday" to your manager before it becomes an issue. Myself and all the best developers I know have days or weeks of doing very little punctuated by days or weeks of doing quite a lot. Of course, I don't lie to my comrades - as intimated by the quip about weeks where the manager leaves, we were very truthful with one another if we actually bothered having a daily scrum. Go ahead and posture online about how you would never overstate your accomplishments to your manager I guess.
        alistairSH 5y ago
        As a manager or co-worker, if you reported "no progress" a few days in a row, I'd ask why not. I would honestly be looking for ways to help you make progress because getting stuck in a rut sucks (and we've all been there). I don't care if some widget in Jira gets moved today or next Monday (but you're making progress to completing that feature/fix/whatever). I do care if you're literally making no progress.
- jimbokun 5y ago
  From the article: > It makes leaders feel in control and informed. They know exactly what was done and when it was completed. > I’m not against management being informed… So seems like there is a little bit of passive aggressive pushback here about having to keep managers updated and in the loop about progressive towards goals.
watwut 5y ago
You can coordinate and report without heavy duty micromanaging process like scrum. And you can achieve much better relationships between people then scrum generates too. The one thing scrum ignores is human psychology. The fact that defense of scrum is so often manipulative, attacking critics personally or twisting what other people said is not good reflection of that system.
- cygned 5y ago
  How does Scrum micromanage and/or ignore human psychology?
  - watwut 5y ago
    Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those. Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations. It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
    - cygned 5y ago
      > Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be. > It creates unnecessary hard social situations Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases. > the components of motivations in pretty much any other fields are autonomy, mastery, accountability You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum. In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.
rxhernandez 5y ago
I don't know about you but I can and do jump on a call with the product managers and my peers the second I run into any issues when it's fresh in my mind; I don't do well at remembering the problem the next morning, an hour after I just woke up. I'm not saying there aren't benefits to scrum but the ones you are stating are poorly done if they are mostly done via scrum.
- vannevar 5y ago
  If you don't remember something the next day, it's probably not important enough to report anyway. Scrum isn't a recitation of minutiae for its own sake, it's a quick summary of progress and blockers. I would hope you could remember what you did or didn't finish yesterday, and whether you're blocked. And it's great that you communicate with your team when you run into a problem. But spending a few minutes each day giving everyone on the team a quick summary of the outcome of those issues shouldn't seem like a big burden and could be helpful given that you're all working on the same project.
  - jjav 5y ago
    > Scrum isn't a recitation of minutiae for its own sake In 12 years of having to deal with the annoying fad of agile/scrum, I've never seen it be anything other than precisely that: "a recitation of minutiae for its own sake".
    - vannevar 5y ago
      Even your own contribution? Scrum is a team thing---if your scrums are terrible, its because you and your teammates like them that way for some reason. You have no one to blame but yourself if you let it go on for 12 years.
      - jjav 5y ago
        That's ~12 years in six different companies. I've never seen it be anything other than an annoying micromanagement technique.
vsareto 5y ago
Idk, I think we waste a lot by doing tickets and meetings for every little thing that has to change. More so for front-end changes than backend changes though.
- jimbokun 5y ago
  I think tickets are more important for auditing purposes, being able to establish what was deployed when and for what purpose. But yes having too many tickets just creates more over head.
jjav 5y ago
> It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it." That's not a good take on it, let alone all boiling down to it by any measure. The constant status reporting of scrum is a distraction. That doesn't of course mean the engineering team shouldn't communicate both plans and results in a timeline that makes sense. If the work is so incredibly trivial that status needs to be reported every.single.day, then it's not work I'm interested in even doing. Progress on anything creative and challenging takes a longer timeline and daily reports are a very annoying distraction.
midrus 5y ago
Nah. I like being told what the mid/long term end result should look like and let me figure out the details and find the best way to that to me and my other engineering team mates. I like to be judged by what we achieved last month, last three months, last 6 months and last year. Not by what I reported in the "daily" what did yesterday because otherwise everyone thinks I've been slacking instead of moving mi Jira tickets. I worked this way I like with just a kan ban board at previous jobs, and at my current one. It works, and everyone is happy. But it requires people with experience and trust at all levels, from engineers to PMs to CTOs to CEOs.

snarf21 5y ago

Well said. Afaik, people aren't getting compensated by LOC * $X. Sometimes the value to the team/product/company is higher by going to pointless meetings than it is by being a code monkey in your basement. No process is perfect but I can't even count the number of man years of wasted and unreleased code because there was no coordination.

ebiester 5y ago
I would argue that pointless is a key modifier here. There are many meetings that are valuable, but they are valuable because people put effort into making that time valuable outside the meeting. Meetings should prove themselves.

commandlinefan 5y ago

> think their job is just lines of code vs accomplishing the business goals That's... not what he said at all. "Getting stuff done" means accomplishing business goals more than it means lines of code, so you're very nearly accusing him of saying the opposite of what he said. Feel free to go into the essay and search/replace "getting stuff done" with "accomplishing business goals" - it still makes sense and is completely accurate. Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable.

vannevar 5y ago
> Modern "scrum" gets in the way of just accomplishing business goals by pretending that they're perfectly predictable. Where did you get that idea? The Agile Manifesto literally says: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Scrum is deliberately incremental precisely because it's designed to accommodate continuously changing business requirements that are NOT predictable.
- ahelwer 5y ago
  Nobody cares what the agile manifesto says. The only way I have ever seen scrum manifest is as a daily meeting where everyone on the team reports their incremental daily progress to the manager. Of course, no developer actually makes uniform incremental daily progress so this really just turns into a demoralizing exercise in lying about what you did the previous day, punctuated by underselling the days where you actually got quite a bit done. Then you tune out as everyone else goes in their turn giving updates on something that doesn't affect what you're doing in any way whatsoever. The best weeks are when the manager goes on vacation so you don't have to put up with the daily bullshit. Also, every manager swears their scrum isn't like this. And every one of them is wrong.
  - worik 5y ago
    > so this really just turns into a demoralizing exercise in lying about what you did the previous day What depressing places you worked. I have worked once at a firm that had a daily meeting of developers. It was very useful, no expectations, we kept each other informed. Why would you lie to your comrades? I can guess answers to that....
    - ahelwer 5y ago
      See how many days in a row you can say "I didn't make progress yesterday" to your manager before it becomes an issue. Myself and all the best developers I know have days or weeks of doing very little punctuated by days or weeks of doing quite a lot. Of course, I don't lie to my comrades - as intimated by the quip about weeks where the manager leaves, we were very truthful with one another if we actually bothered having a daily scrum. Go ahead and posture online about how you would never overstate your accomplishments to your manager I guess.
      - alistairSH 5y ago
        As a manager or co-worker, if you reported "no progress" a few days in a row, I'd ask why not. I would honestly be looking for ways to help you make progress because getting stuck in a rut sucks (and we've all been there). I don't care if some widget in Jira gets moved today or next Monday (but you're making progress to completing that feature/fix/whatever). I do care if you're literally making no progress.
jimbokun 5y ago
From the article: > It makes leaders feel in control and informed. They know exactly what was done and when it was completed. > I’m not against management being informed… So seems like there is a little bit of passive aggressive pushback here about having to keep managers updated and in the loop about progressive towards goals.

watwut 5y ago

You can coordinate and report without heavy duty micromanaging process like scrum. And you can achieve much better relationships between people then scrum generates too. The one thing scrum ignores is human psychology. The fact that defense of scrum is so often manipulative, attacking critics personally or twisting what other people said is not good reflection of that system.

cygned 5y ago
How does Scrum micromanage and/or ignore human psychology?
- watwut 5y ago
  Micromanagement - there is literally ability to make own decisions. You have to accountability either. Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. Personal guess: groups full of people with high interest in people and great social skills won't produce something like scrum. It exists only because tech can give decision power to people who don't have those. Human psychology: to large extend the above. It leads to absurd conflicts and power struggles over nonsense. Then it blames people who actually reacted in predictable way. It creates unnecessary hard social situations. It is also massively demotivating. In fact, the components of motivations in pretty much any other fields are autonomy, mastery, accountability. Scrum lacks all three.
  - cygned 5y ago
    > Every single tiny aspect of work is dictated by somebody else, commitee or some kind of process. That is not the way Scrum is meant to be implemented. The goal is to have a cross-functional, empowered team with the ability to make their own decision. The Product Owner - as part of that team - makes ultimate decisions as to what the product will be. > It creates unnecessary hard social situations Yes, social conflicts in team can be tough. Following the values of Scrum, respect and openness in particular, helps teams sort these things out. I know that in practice, it involves a lot of skill to guide a team through those phases. > the components of motivations in pretty much any other fields are autonomy, mastery, accountability You are absolutely right. If you read through the Scrum guide, you will find all those aspects in there. I think what you are describing, though, is how Scrum is "lived" in many organizations, which have difficulties empowering teams and provide the environment necessary to do Scrum. In these situations, the answer is often that Scrum simply don't work, it's clashing with your culture and structure. Many teams opt to implement parts of Scrum - which is fine and might work exceptionally well, but it's not Scrum.

rxhernandez 5y ago

I don't know about you but I can and do jump on a call with the product managers and my peers the second I run into any issues when it's fresh in my mind; I don't do well at remembering the problem the next morning, an hour after I just woke up. I'm not saying there aren't benefits to scrum but the ones you are stating are poorly done if they are mostly done via scrum.

vannevar 5y ago
If you don't remember something the next day, it's probably not important enough to report anyway. Scrum isn't a recitation of minutiae for its own sake, it's a quick summary of progress and blockers. I would hope you could remember what you did or didn't finish yesterday, and whether you're blocked. And it's great that you communicate with your team when you run into a problem. But spending a few minutes each day giving everyone on the team a quick summary of the outcome of those issues shouldn't seem like a big burden and could be helpful given that you're all working on the same project.
- jjav 5y ago
  > Scrum isn't a recitation of minutiae for its own sake In 12 years of having to deal with the annoying fad of agile/scrum, I've never seen it be anything other than precisely that: "a recitation of minutiae for its own sake".
  - vannevar 5y ago
    Even your own contribution? Scrum is a team thing---if your scrums are terrible, its because you and your teammates like them that way for some reason. You have no one to blame but yourself if you let it go on for 12 years.
    - jjav 5y ago
      That's ~12 years in six different companies. I've never seen it be anything other than an annoying micromanagement technique.

vsareto 5y ago

Idk, I think we waste a lot by doing tickets and meetings for every little thing that has to change. More so for front-end changes than backend changes though.

jimbokun 5y ago
I think tickets are more important for auditing purposes, being able to establish what was deployed when and for what purpose. But yes having too many tickets just creates more over head.

jjav 5y ago

> It ultimately boils down to "I don't want to report on what I am doing or how I plan on doing it." That's not a good take on it, let alone all boiling down to it by any measure. The constant status reporting of scrum is a distraction. That doesn't of course mean the engineering team shouldn't communicate both plans and results in a timeline that makes sense. If the work is so incredibly trivial that status needs to be reported every.single.day, then it's not work I'm interested in even doing. Progress on anything creative and challenging takes a longer timeline and daily reports are a very annoying distraction.

midrus 5y ago

Nah. I like being told what the mid/long term end result should look like and let me figure out the details and find the best way to that to me and my other engineering team mates. I like to be judged by what we achieved last month, last three months, last 6 months and last year. Not by what I reported in the "daily" what did yesterday because otherwise everyone thinks I've been slacking instead of moving mi Jira tickets. I worked this way I like with just a kan ban board at previous jobs, and at my current one. It works, and everyone is happy. But it requires people with experience and trust at all levels, from engineers to PMs to CTOs to CEOs.